Attachment 1 Functional Specifications.pdf

DHHS Vital Records Department Modernization Requirements

Bidder Name: (Enter Bidder Name here)

Ref System Modules and Specifications Vendor Selection Vendor Response

1 GENERAL

1.1 COMPONENT

1.1.1 The system must include the following modules:

1.1.1.1* Birth;

1.1.1.2* Death;

1.1.1.3* Marriage;

1.1.1.4* Dissolution of Marriage;

1.1.1.5* Fetal Death;

1.1.1.6* Induced Termination of Pregnancy (ITOP);

1.1.1.7* Order Management.

1.1.2* The system must contain a report builder tool or associated utility.

1.2 SYSTEM

1.2.1* The system must not require the purchase of any additional proprietary applications.

1.2.2* The system must support multiple environments, specifically, System Integration Testing (SIT), User Acceptance Testing (UAT), Training, Development, and Production.

1.2.3 The system should be configurable to present module fields in the order listed on its corresponding form.

1.2.4* The system must have images be seamlessly accessible within the application.

1.2.5 The system should provide functionality to disallow any other screen shot tool, such as the “Snipping Tool” or the like.

1.2.6 The system should provide a managed print function.

1.2.7 The system should capture an audit log when the print function is used.

1.2.8* The system's implementation and functionality must adhere to the technical specifications outlined in the accompanying Technical Specifications-Attachment 3.

1.2.9* The system must support a minimum of 5,000 internal and external users.

1.2.10* The system must support a minimum of 1,000 concurrent users regardless of user role and/or location.

1.2.11 The system should provide online help connected to the relevant routine, field, or report being used.

1.2.12* The system must have the ability to connect to local or network printers.

1.2.13* The system must have the ability to connect to local or network scanners.

1.3 DATA

1.3.1* The system must have the ability to complete a data conversion of all existing data, including images and files.

1.3.2* The system must have configurable data retention rules.

1.3.3* The system must provide immediate validation and error messaging needed for data interfaces.

1.3.4* The system must have the ability to use field-level data integrity checks and data validation (e.g., numeric fields, verify a number is entered, date fields, verify a date is entered, etc.).

1.3.5* The system must provide an integrated full-featured word processing function (including superscript, subscript, and scientific notations, cut and paste, and word wrap) to allow a user to enter data into large text fields.

1.3.6* The system must validate against an integrated medical dictionary for medical related fields.

1.3.7* The system must have real-time processing of data.

1.3.8* The system must align with State of Nebraska and Federal guidelines to collect vital statistic data and other data points needed for federal reporting and evaluation purposes.

1.3.9* The system must have graphical control elements to assist with data entry (e.g., checkbox, drop-down box, etc.).

1.4 FUNCTIONALITY

1.4.1* The system must have the ability to scan directly into the system.

1.4.2* The system must have the ability to attach a file with a minimum of the following file types (.pdf, .doc, .jpeg, .png, .tiff).

1.5 CONFIGURATION

1.5.1* The system must have configurable field level warning notifications.

1.5.2 The system should auto advance a user from process start through process completion.

1.5.3 The system should have task list or work queue functionality.

1.5.4* The system must have the ability to configure workflows.

2 USERS

Attachment 1 - Functional Specifications

RFP: 120277 O3 REBID

Vital Records Management System State of Nebraska, Department of Health and Human Services Bidders are to follow

Instructions given on the first tab, "Instructions" for directions regarding how to respond.

The items highlighted in gold and notated with an asterisk (*) within this document represent the capability and/or requirement that will be subject to the “Pass” or “Fail” assessment, as these are “must” requirements.

Functional Specifications Page 1 of 8

2.1 GENERAL

2.1.1* The system must allow a user with necessary access to create a record, image, or attachment.

2.1.2* The system must allow a user with necessary access to view a record, image, or attachment.

2.1.3* The system must allow a user with necessary access to search a record, image, or attachment.

2.1.4* The system must allow a user with necessary access to update a record, image, or attachment.

2.1.5* The system must allow a user with necessary access to save a record, image, or attachment.

2.1.6* The system must allow a user with necessary access to delete or purge a record, image, or attachment.

2.1.7* The system must allow a user with necessary access to deactivate a record, image, or attachment.

2.1.8* The system must have the ability to register a user for system access based on role and location.

2.2 ACCESS

2.2.1* The system must allow access to both internal (State of Nebraska employees) and external users (e.g., funeral directors, hospital staff, and county clerks).

2.2.2* The system must have role-based security for application and administrative functions including views for all user roles across all modules.

2.2.3* The system must provide a location selection prompt for users who have access to multiple locations.

2.2.5 The system should have the ability for a new user to complete a registration form.

2.2.6* The system must have the ability for a user to complete self-service password changes and/or resets.

2.2.7* The system must have the ability for a user to update their own user profile demographics once logged in (non-system security).

2.2.8* The system must provide a warning message after user login based on a configurable time period when a password is expiring.

2.2.9* The system must perform an automatic logoff for session inactivity based on a configurable length of time.

2.2.10* The system must provide a warning message prior to automatic logoff for session inactivity based on a configurable length of time.

2.3 SEARCH

2.3.1* The system must allow a user with necessary access the ability to use a real-time search and filter function whereas all vital event records, requests, orders, payments, and invoices can be viewed, searched, and filtered by one or more data fields or variables in each record, and wildcards or partial entry of a field can be used.

2.3.2* The system must allow a user with necessary access to export search results.

2.3.3* The system must allow a user with necessary access to print search results.

2.3.4* The system must have the ability to limit the number search result count by user.

2.4 FUNCTIONALITY

2.4.1* The system must have the ability for a user with the necessary access to create a new user and associate that user to specific user role(s).

2.4.2* The system must have the ability for a user with the necessary access to delete a user.

2.4.3* The system must have the ability to search the system for a user, including a filter to search for an expired user.

2.4.4* The system must have the ability for a user with the necessary access to deactivate a user.

2.4.5* The system must allow a user with necessary access to bypass security and update any entry when needed.

2.4.6 The system should allow a user with necessary access the ability to view more detailed information on any field when appropriate.

2.4.7* The system must allow a user with necessary access to attach, link, and view any supporting document of any file format to a record or order.

2.5 CONFIGURATION

2.5.1* The system must have the ability to edit validation data through a front-end utility.

3 SYSTEM ADMIN

3.1 ACCESS

3.1.1* The system must have a user role with elevated security access to the system (e.g., System Administrator).

3.1.2 The system should have system-level access to exports (create, configure).

3.1.3 The system should have system-level access to imports (create, configure).

3.1.4 The system should have system-level access to reports (create, configure).

3.1.5 The system should have system-level access to documents (create, configure).

3.2 DATA

3.2.1* The system must use a centralized data dictionary that fully describes table structure and appropriate levels of metadata.

3.2.2* The system must allow a user with necessary access to have read-only access to the system's database(s).

3.2.3 The system should allow a user with necessary access to have full access to the system's database(s).

3.3 FUNCTIONALITY

3.3.1 The system should have the ability to edit (e.g., checkbox, drop-down box, etc.).

3.3.2 The system should have the ability for the system administrators to create user roles.

3.3.3 The system should have the ability for the system administrators to modify user roles.

3.3.4 The system should have the ability for the system administrators to delete user roles.

3.3.5 The system should have the ability for system administrators to terminate a user connection and/or session remotely.

3.3.6 The system should have the ability to maintain a directory of all personnel currently active in the system.

3.3.7* The system must have the ability to produce a system access log (in/out history) by user with time stamp in seconds.

3.3.8 The system should allow the system administrator to make batch updates to data on admin-specified criteria (i.e., system-wide find/change functionality).

3.3.9 The system should allow the system administrator to schedule batch updates to data on admin-specified criteria (i.e., system-wide find/change functionality).

4 AUDIT LOGS

4.1 GENERAL

Functional Specifications Page 2 of 8

4.1.1 The system must have action history logs to view modifications, deletions, data loading actions, reports, printing, and user log-ins/outs. At a minimum the log must contain the following:

4.1.1.1* User;

4.1.1.2* Date;

4.1.1.3* Time;

4.1.1.4* Data Prior to Edit;

4.1.1.5* Data After Edit.

4.1.2 The system must have audit history logs to view user activities, such as logging in and out of the system. At a minimum the log must contain the following:

4.1.2.1* User;

4.1.2.2* Date;

4.1.2.3* Time.

4.1.3* The system must track changes made to all data, keeping the integrity of the original document, data, and image with associated changes.

4.1.4* The system must provide the ability to create, save, and export an audit log of the tracked changes made throughout the system.

4.1.5* The system must maintain a history of all data.

4.2 ORDER MANAGEMENT

4.2.1* The system must track the data associated with serialized forms used within each order.

4.2.2* The system must be able to store a user-defined, customizable volume of sales transactions, categorized by transaction date, for a minimum of five years.

4.2.3* The system must contain reporting capabilities to assist with audit of document control number/certificate paper to the associated receipt and order, including by registrar and date.

4.3 CERTIFIED PAPER

4.3.1* The system must track the number of certificates printed by vital event record and certificate type.

4.3.2* The system must track the serial number of issuance in chronological order within a print log.

4.4 FUNCTIONALITY

4.4.1* The system must capture an audit of all imports.

4.4.2* The system must capture an audit of all exports.

4.4.3* The system must allow a user with necessary access to search the audit log.

4.4.4* The system must track the creating, viewing, printing, and deleting of attachments.

4.5 CONFIGURATION

4.5.1* The system must track and maintain an audit log of when configuration changes are made (e.g., changes to fees for certification types).

5 ALL MODULES

5.1 GENERAL

5.1.1* The system must contain all existing and future records or orders with any associated images and/or attachments synchronously.

5.1.2* The system must incorporate all previously available records or orders with any associated data or attachments from the current system.

5.1.3* The system must allow a user with necessary access the ability to print an attachment.

5.1.4* The system must allow input of a partial record or order without forcing a user to complete a process.

5.1.5* The system must validate and issue vital event records.

5.1.6* The system must allow a user with necessary access to view, change, and submit a record or order.

5.1.7* The system must allow a user with necessary access to view, print, store, attach and scan documents or images into a record or order.

5.1.8* The system must allow a user to save a record or order regardless of completed data except for fields that are flagged as required by the State of Nebraska.

5.1.9* The system must have administrative tools to be customizable to meet specific user needs.

5.1.10 The system should save user data entry progress automatically upon moving to the next field on the form.

5.1.11 The system should allow the saving and pausing activity on one record or order and moving to a different record or order for processing.

5.2 SEARCH

5.2.1* The system must allow a user the ability to group, sort and count search result data.

5.2.2* The system must allow a user with necessary access to search for a record or order using various metadata fields.

5.2.3* The system must provide a real-time search and filter function whereas all vital event records, requests, orders, payments, and invoices can be electronically viewed, searched, and filtered by one or more data fields or variables in each record, and wildcards or partial entry of a field can be used.

5.2.4* The system must allow a user with necessary access to manipulate search parameters.

5.2.5* The system must allow a user with necessary access to save search parameters individually or to a group.

5.2.6* The system must allow a user with necessary access to export (to Excel) search results.

5.2.7* The system must allow a user with necessary access to print search results.

5.2.8* The search feature must have the ability to manipulate the number of records captured in a search by the user.

5.2.9* The system must allow a user to render searches of over 1,000 vital events at a time.

5.3 CORRESPONDENCE

5.3.1* The system must have the ability to generate letters for customer correspondence.

5.3.2* The system must have the ability to view previously generated and/or sent customer correspondence.

5.3.3* The system must have the ability to edit and send customer correspondence.

5.3.4* The system must have the ability to resend previously sent customer correspondence.

Functional Specifications Page 3 of 8

5.4 DOCUMENTATION

5.4.1* The system must have standard forms, permits, and worksheets that are accessible for a user with necessary access.

5.4.2* The system must have the ability to propagate data onto documents, forms, permits, and worksheets.

5.4.3* The system must have document management storage to house all certificates and associated supporting documents to be tied to the original records (e.g., adoptions).

5.5 FIELDS

5.5.1 The system should provide real-time validation for an entered address and prompt if not valid.

5.5.2 The system should be able to populate validated country, state, county, city, and zip code based on selected address.

5.5.3 The system should prompt if a suite number is appropriate.

5.5.4 The system should prompt with any suggested address alternative.

5.5.5* The system must have a consistent data input and display format for time across all modules.

5.5.6* The system must have a consistent data input and display format for phone numbers across all modules.

5.5.7* The system must have a consistent data input and display format for zip codes across all modules.

5.5.8* The system must have a consistent data input and display format for dates across all modules.

5.5.9* The system must have a consistent data input and display format for whole numbers, decimals, and amounts across all modules.

5.5.10* The system must have the proper data input and display format for social security numbers "000-00-0000" across all modules.

5.5.11* The system must provide spell check functionality for freeform text entry fields as designated by the State of Nebraska.

5.5.12* The system must have the ability for a user to accept or ignore spell check suggestions.

5.5.13* The system must have the ability to customize (e.g., add to dictionary) the spell check functionality by user with necessary access.

5.5.14* The system must have the ability to configure any data field (user-defined and standard) to be "required" during data entry.

5.5.15* The system must populate data entered into a field throughout the record or order if data is associated.

5.5.16* The system must ensure that a record is not complete until all required fields pass validity checks.

5.6 ALERTS

5.6.1* The system must have prompts tied to various data fields to alert the user of questionable or incorrect data.

5.6.2* The system must, at a minimum, follow the requirements for collecting and editing data as specified by National Vital Statistics System (NVSS), provided here:

https://www.cdc.gov/nchs/nvss/revisions-of-the-us-standard-certificates-and-reports.htm 5.6.3* The system must have configurable alerts which notifies the user of the status of the record they are accessing (e.g., OVS return status, child is deceased).

5.7 QUEUE

5.7.1* The system must provide a user with a view that highlights important information, notifications, and warnings (e.g., incomplete vital event records sorted by queue).

5.7.2* The system must queue an incomplete record or order.

5.8 WORKFLOW

5.8.1* The system must have configurable workflows.

5.8.2* The system must have automated workflow process for the electronic signature or completion of a record or order.

5.8.3* The system must have the ability to automatically route a record or order to different users involved in the completion, registration and certification process of the record or order.

5.8.4* The system must have the ability to automatically transfer a record or order to different users involved in the completion, registration and certification process of the record or order.

5.9 FUNCTIONALITY

5.9.1* The system must allow a user with necessary access the ability to query, override, or bypass defined fields.

5.9.2 The system should have the ability to send secure messages to any user within the respective module.

5.9.3 The system should have the ability to create and track timelines based on actual calendar or business days.

5.9.4* The system must ensure that when a record or order is completed by an end user the record or order can no longer be manipulated by end user.

5.9.5* The system must have the ability to place or remove a record from an administrative hold or alert, which is only put in place by a user with necessary access. This hold would disallow the printing of legal certified copies of a certificate.

5.9.6* The system must allow a user with necessary access to view, print, crop, rotate and resize a vital event certificate image.

5.9.7* The system must allow a user with the necessary access the ability to print attachments.

5.9.8* The system must provide the ability to print a blank form.

6 ALL VITAL EVENT REGISTRATION MODULES

6.1 GENERAL

6.1.1* The system must be able to accommodate rejected vital event records, including queues for viewing the rejected records.

6.1.2* The system must have the ability to manipulate and retain the original vital event record in the case of processing an amendment.

6.2 REGISTER

6.2.1 The system must encompass the end-to-end process of registering the following vital events:

6.2.1.1* Birth;

6.2.1.2* Death;

6.2.1.3* Marriage;

6.2.1.4* Dissolution of Marriage;

6.2.1.5* Fetal Death;

Functional Specifications Page 4 of 8

6.2.1.6* Induced Termination of Pregnancy (ITOP).

6.3 FUNCTIONALITY

6.3.1* The system must allow the collection of all vital record data with both data rules and field validations, based on the NCHS (National Center for Health Statistics) Standard Record layout or the Inter-Jurisdictional Exchange (IJE) file layout.

6.3.2* The system must have a process to void a vital event record.

6.3.3* The system must automatically route a vital event record through the predefined workflow, advancing it from one user to the next in the appropriate sequence until the record is completed and finalized.

6.3.4* The system must generate and assign a unique and sequential State File Number for each vital event record.

6.3.5* The system must allow a user with necessary access the ability to change a State File Number.

6.3.6* The system must automatically search for duplicate vital event records and, if found, alert user.

6.3.7* The system must be designed so that no duplicate vital event record can be entered. The system must use fields designated by the State of Nebraska for duplicate checks.

6.3.8* The system must allow a vital event record to be corrected with the assignment of correction indicators (e.g., affidavit/correction number, “amendment” notation, and amended date).

7 COMBINED MODULES

7.1 BIRTH & DEATH

7.1.1* The system must have the ability to identify records where birth and death record data does not match (e.g., when a death record does not have a corresponding birth record).

7.1.2* The system must have the ability to match and link birth and death records together.

7.2 DEATH & FETAL DEATH

7.2.1* The system must provide spell check functionality for the cause of death or medically related fields.

7.2.2* The system must allow for querying a medical certifier after a vital event record has been filed with a State File Number.

7.3 BIRTH, DEATH, & FETAL DEATH

7.3.1* The system must validate based on the Inter-Jurisdictional Exchange (IJE) standard.

7.3.2* The system must allow for local registration by counties as specified by the State of Nebraska before registration at the state-level.

7.4 BIRTH, DEATH, FETAL DEATH, MARRIAGE, & DISSOLUTION OF MARRIAGE

7.4.1* The system must have the ability to print non-certified copies of certificates from the Birth, Death, Fetal Death, Marriage, and Dissolution of Marriage Modules.

7.4.2* The system must store the State and Local Registrar's information that is to be added based on the file date on validated state vital event records.

7.5 MARRIAGE & DISSOLUTION OF MARRIAGE

7.5.1* The system must have document forms, licenses, and worksheets that are accessible to a user with necessary access.

8 BIRTH MODULE

8.1 BIRTH MODULE

8.1.1* The system must have the ability to enter a delayed birth record, new adoption record, and a foreign-born birth record.

8.1.2* The system must have the ability to flag and unflag a birth record as deceased.

8.1.3* The system must pre-load data flagged by the State of Nebraska for multiples birth records (e.g., twins, triplets).

8.1.4 The system should auto-fill stored birth attendant information maintained by the facility.

9 DEATH MODULE

9.1 DEATH MODULE

9.1.1* The system must allow a user with necessary access the ability to save a death record without the cause of death indicated, as a pending investigation record.

9.1.2* The system must provide a connection to Validations and Interactive Edits Web Service (VIEWS) to review medically related fields.

9.1.3* The system must allow a user with necessary access to sign permits.

10 MARRIAGE MODULE

10.1 MARRIAGE MODULE

10.1.1* The system must automatically file a marriage record that has fulfilled State of Nebraska specific criteria.

10.1.2* The system must auto-fill county clerk and fee information.

11 DISSOLUTION OF MARRIAGE MODULE

11.1 DISSOLUTION OF MARRIAGE MODULE

11.1.1* The system must automatically file a dissolution of marriage record that has fulfilled State of Nebraska specific criteria.

12 FETAL DEATH MODULE

12.1 FETAL DEATH MODULE

12.1.1* The system must automatically search for associated birth events upon record entry, in the event a fetal death occurs, an error message must display for the affected user.

13 ORDER MANAGEMENT MODULE

13.1 GENERAL

13.1.1* The system must allow a user with necessary access to issue certified copies of an individual certificate.

13.1.2* The system must support the ordering and purchase of a commemorative certificate for a nonviable birth event.

13.1.3* The system must provide a user with necessary access the ability to manage all transactions.

13.1.4* The system must link the order to vital event record.

13.1.5* The system must link the order to an invoice and payment.

Functional Specifications Page 5 of 8

13.1.6 The system should connect all issued controlled documents (serialized certificate paper) to a receipt and to an order.

13.1.7 The system must support the ordering, purchase, and printing of legal certified copies of certificates on security paper for the following vital events:

13.1.7.1* Birth;

13.1.7.2* Death;

13.1.7.3* Marriage;

13.1.7.4* Dissolution of Marriage;

13.1.7.5* Fetal Death;

13.1.7.6* Birth Resulting in Stillbirth.

13.2 SYSTEM

13.2.1* The system must generate and assign a unique and sequential transaction number for each sales transaction.

13.2.2* The system must generate and assign a unique and sequential invoice number for each invoice.

13.2.3* The system must allow a user with necessary access to flag returned certificates on the order.

13.2.4* The system must generate and assign a unique and sequential number for each print transaction of a legal certified copy a of certificate.

13.2.5* The system must allow a user with necessary access to print a legal certified copy of a certificate from an altered (cropped, rotated, resized) vital event certificate image.

13.2.6* The system must have a process to link, safeguard, and store serialized security paper identifiers.

13.3 ORDERS

13.3.1* The system must have the ability to process regular mail orders.

13.3.2* The system must have the ability to add internal notes to an order without restricting the length.

13.3.3* The system must enter and save shipping information, including shipping method and address.

13.3.4* The system must have the ability to post by line item and fee.

13.3.5* The system must have the ability to calculate accurate charges based on quantity of documents requested.

13.3.6* The system must have the ability to set up a fee schedule by vital record document type, including effective and termination dates to the fees.

13.3.7* The system must have the ability to set multiple fees for each vital record document type.

13.4 DATA

13.4.1* The system must be able to track the certificate type.

13.4.2* The system must be able to track the method of certificate delivery.

13.5 DOCUMENTS

13.5.1* The system must maintain a record of all printed certificates that are destroyed, including method and reason for destruction.

13.5.2* The system must have the ability to attach files with a minimum of the following file types (PDF, .doc, .jpeg, .png, .tiff) to an order.

13.5.3* The system must have the ability to mark a document control number as "destroyed" with a reason for discarding (e.g., poor print quality, printing error, etc.).

13.6 QUEUE

13.6.1* The system must have the ability to queue orders based on status.

13.7 PAYMENTS

13.7.1 The system must have the ability to support the following payment types:

13.7.1.1* Debit Card;

13.7.1.2* Credit Card;

13.7.1.3* Money order;

13.7.1.4* Check;

13.7.1.5* Cash.

13.7.2* The system must enforce mandatory field validation to prevent payment processing before all required fields are populated, as mandated by the State of Nebraska.

13.7.3* The system must have the ability to track payment status (i.e., refund, payment, discounted/free, or no payment).

13.7.4* The system must have cash handling capabilities for each cashier station.

13.8 PRINT

13.8.1* The print queue must list pending document print jobs, including approval status. Document Control Numbers must be assigned at print time and recorded in the database.

13.8.2* The system must allow a user with necessary access the ability to print a replacement of a legal certified copy of a certificate.

13.8.3* The system must provide the ability to print a certificate with amendments.

13.8.4 The system should print labels of various sizes, as needed for mailings, etc.

13.8.5* The system must have the ability to print a batch of documents.

13.8.6* The system must have the ability to reprint a batch of documents.

13.8.7 The system should have the ability to print common correspondence letters.

13.8.8* The system must not allow a record with a specific status to be printed.

13.8.9* The system must have the ability to print and reprint an invoice.

13.8.10* The system must have the ability to print and reprint a receipt.

13.9 SHIP

13.9.1 The system should have the ability to ship orders via UPS or USPS.

13.9.2 The system should have the ability to generate shipping labels to be printed, or blank labels that need to be handwritten.

13.9.3 The system should have the ability to void a shipping label.

Functional Specifications Page 6 of 8

13.9.4 The system should have the ability to view and access shipping functions.

13.9.5 The system should have the ability to generate a detailed report with an existing or previous shipping vendor manifest (e.g., when a manifest is created, an email is sent, notifying the customer their order has been shipped).

13.10 FUNCTIONALITY

13.10.1 The system should provide a kiosk provided and maintained by the Vendor for the processing of vital record order requests and process payments for customers.

13.10.2 The system should provide credit card machines provided and maintained by the Vendor for the processing of payments for customers.

13.10.3* The system must track requests and accept payment for all transactions.

13.10.4* The system must have the ability to calculate order fees automatically.

13.10.5* The system must allow manual processing of checks, money orders, or cash payments for orders including the requestor, request reason, amount, and request type.

13.10.6* The system must have the ability to close orders.

13.10.7* The system must allow a user with necessary access to void an order that has been paid in full.

13.10.8* The system must allow a user with necessary access to void an order before it is closed.

13.10.9* The system must allow a user with necessary access to make updates to a completed order.

13.10.10* The system must allow a user with necessary access to cancel an unpaid order.

13.10.11* The system must allow a user with necessary access to process individual orders.

13.10.12* The system must have a specific status for certificates that are waiting on verification.

13.10.13* The system must have an automated workflow to assign a specific status to certificates waiting on verification, this status would disallow the issuance of the certificate.

13.10.14* The system must have the ability to process refunds.

13.10.15* The system must have the ability to generate order slips.

13.10.16* The system must be able to track how staff validated identity and eligibility of the person requesting the certificate.

13.10.17* The system must produce a receipt for each order transaction based on fields that are stipulated by the State of Nebraska.

13.10.18* The State maintains its own credit card processor. The vendor must ensure compatibility with this system. The vendor is not responsible for payment processing.

13.11 CONFIGURATION

13.11.1* The system must have the ability to add, update, or configure custom fees with a date parameter.

13.11.2* The system must allow a user with necessary access to configure the invoice template.

13.11.3* The system must allow a user with necessary access to configure the order slip template.

14 REPORTS

14.1 GENERAL

14.1.1* The system must have the ability to create or modify reports.

14.2 FUNCTIONALITY

14.2.1* The system must allow a user with necessary access to generate a report of detailed and/or summary financial reports by user, terminal, or submission source and current status.

14.2.2* The system must allow a user with necessary access to view custom, on-demand, or ad-hoc reports of any data, orders, payments, or records in the system.

14.2.3* The system must allow a user with necessary access to create custom, on-demand, or ad-hoc reports of any data, orders, payments, or records in the system.

14.2.4* The system must allow a user with necessary access to copy custom, on-demand, or ad-hoc reports of any data, orders, payments, or records in the system.

14.2.5* The system must allow a user with necessary access to update custom, on-demand, or ad-hoc reports of any data, orders, payments, or records in the system.

14.2.6* The system must allow a user with necessary access to delete custom, on-demand, or ad-hoc reports of any data, orders, payments, or records in the system.

14.2.7* The system must allow a user with necessary access to schedule and deliver custom, on-demand, or ad-hoc reports of any data, orders, payments, or records in the system.

14.2.8 The system should allow a user with necessary access to export or download custom, on-demand, or ad-hoc reports of any data, orders, payments, or records in the system.

14.2.9* The system must allow a user with necessary access to print or reprint custom, on-demand, or ad-hoc reports of any data, orders, payments, or records in the system.

14.3 CONFIGURATION

14.3.1 The system should allow a user with necessary access to configure letter templates.

14.3.2 The system should have the ability to customize template letterhead.

15 INTEGRATION

15.1 INTERFACE

15.1.1* The system must integrate with the State and Territorial Electronic Vital Event (STEVE), Social Security Administration (SSA), Electronic Verification of Vital Events (EVVE), and internal state agencies for data collection and reporting purposes.

15.1.2* The system must securely integrate with various state agency systems for sharing HIPAA related data.

15.1.3* The system must integrate with the State of Nebraska's Vital Records unit's online order management application.

15.1.4 The system should integrate with the State of Nebraska's financial system for all collected revenue.

15.2 IMPORT

15.2.1* The system must provide the ability to import files including but not limited to the Inter-Jurisdictional Exchange (IJE) standard.

15.2.2* The system must generate error files identifying import failures.

15.2.3* The system must generate error prompt boxes identifying any manual import failures.

15.2.4* The system must have the ability to electronically schedule imports.

15.2.5* The system must have the ability to cancel or reverse a data import which would automatically remove the imported record and/or associated data.

15.2.6* The system must have an import process; as the data file is imported, values on the file should be able to be validated or decoded.

15.2.7* The system must have the ability to decode or populate import data based on missing or incomplete values (e.g., table validation, stored procedure, or default values).

Functional Specifications Page 7 of 8

15.2.8* The system must import dissolution of marriage events from the State of Nebraska's Justice System data daily (format fixed width).

15.2.9* The system must provide the ability to import or lookup coded files from the National Center for Health Statistics (NCHS) in accordance with their reporting requirements, and once uploaded have the ability to insert these imported files (codes) and place them in to the appropriate fields attached to the applicable records. This includes International Classification of Diseases (ICD)-10 codes and bridge-race codes.

See www.cdc.gov/nchs/nvss/revisions-of-the-us-standard-certificates-and-reports.htm

15.3 EXPORT

15.3.1* The system must provide the functionality to transmit from all death records the decedent’s data to the Social Security Administration (SSA). This functionality meets the terms and conditions under which SSA will verify SSN’s (social security numbers) for the State of Nebraska.

15.3.2* The system must generate error files identifying export failures.

15.3.3* The system must generate error prompt boxes identifying any manual export failures.

15.3.4* The system must have the ability to electronically schedule exports.

15.3.5* The system must have an export process; as the data file is produced, values on the file should be able to be validated or decoded.

15.3.6* The system must have the ability to produce standard or ad hoc data exports with a file type (.xlsx, .csv, .txt, .pdf) of complete or partial information and/or records.

15.3.7* The system must have a way for the State of Nebraska to automate control of when a record needs to be sent or resent.

16 ANALYTICS TOOL

16.1 ANALYTICS TOOL

16.1.1 The system should have an analytics tool within the system to identify data duplication, discrepancies, and outliers.

16.1.2 The system should have the ability to apply data visualizations such as charts, graphs, and dashboards, which can be drilled into for more granular information.

17 HELP

17.1 HELP

17.1.1* The system must provide online help connected to the relevant workflow, field, or report being used.

17.1.2 The system should provide an overall up-to-date online tutorial to assist users learning the software as well as online help tool with glossary, index, and search capabilities.

17.1.3 The system should provide online documentation for all modules.

Functional Specifications Page 8 of 8