The file's text, extracted by GovTribe without its formatting.
ATTACHMENT A
Colorado MHI Glucometer Requirements
Indicate with a Y=Yes or a N=No if your proposed solution meets the following requirements.
THIS TEMPLATE SHALL BE COMPLETED AND RETURNED WITH OFFEOR’S RESPONSE
| Type |
| # |
| Specification |
| Y or N |
| Section |
| A |
| General Functional Requirements |
| Requirement |
| A.1 |
| The system must adhere to regulatory standards |
| Offeror Response |
| A.1 |
| [Offeror must provide a written response in this text box to the requirement above that describes how the requirement will be met, including estimates of the percent: met by the core system, met by the Offeror modifying the core system, or met by CDHS staff modifying the system with the tools provided with the system.] |
| Description |
| 1 |
| The system supports use of standard and approved medical and other user-defined specialized acronyms, abbreviations, eponyms and symbols. |
| Description |
| 2 |
| The system monitors the use of abbreviations and provides alerts for unapproved medical abbreviations (e.g. do not use abbreviations) defined by users. |
| 3 |
| The Offeror provides that the system is HIPAA compliant, including a minimum of 128-bit encryption. |
| 4 |
| The vendor assures that the system will follow required HIPAA Electronic protected health information (ePHI) security regulations, to include, but not be limited to the following: |
a. Automatic Logoff: the proposed system employs inactivity timers or automatic session logoff mechanisms to automatically terminate after a predetermined number of minutes of inactivity to protect ePHI.
b. Integrity and confidentiality of the information within the proposed system is ensured.
c. Employs round-trip encryption between glucometer and .
| 5 |
| The system supports the state’s browser standard, which is Microsoft Internet Explorer or Google Chrome. |
| 6 |
| The system locks user accounts after three failed log-in attempts. Locked accounts are enabled by the system Administrator. |
| Requirement |
| A.2 |
| The Offeror must propose an existing Commercial Off the Shelf (COTS) system that meets the requirements set forth herein for web-based data management solutions to both manage glucose meters and transfer patient glucose data between meters and the EHR (Electronic Health Record) System. |
| Offeror Response |
| A.2 |
| [Offeror must provide a written response in this text box to the requirement above that describes how the requirement will be met, including estimates of the percent: met by the core system, met by the Offeror modifying the core system, or met by CDHS staff modifying the system with the tools provided with the system.] |
| Offeror Response |
| 1 |
| Preference is for a Non-Hosted Solution. |
| Offeror Response |
| 2 |
| Preference is for a virtual or server-based system to be installed upon a State-owned server. |
| Offeror Response |
| 3 |
| Preference is for ODBC database compliancy. |
| Offeror Response |
| 4 |
| System shall recognize and use DHCP IP Addressing |
| Offeror Response |
| 5 |
| Offeror shall ensure all software licenses for this system will belong to the State of Colorado. |
| Offeror Response |
| 6 |
| System shall not be hardware specific. |
| Offeror Response |
| 7 |
| Database and server shall be managed by the State. |
| Offeror Response |
| 8 |
| System supports two independent data sites using one database. |
| Offeror Response |
| 9 |
| System supports server compatibility to Windows Server 2008. |
| Offeror Response |
| 10 |
| System supports database compatibility to Windows Server 2008 |
| Offeror Response |
| 11 |
| System supports TCP/IP protocol |
| Offeror Response |
| 12 |
| The Offeror’s system is fully integrated thereby eliminating redundant data entry. Data entered in one function shall be available to other functions without duplicate data entry. |
| Offeror Response |
| 13 |
| The system is scalable to meet the current and future needs of the two Colorado State Mental Health Institutes. |
| Offeror Response |
| 14 |
| The system allows users to access and transfer patient records across the two hospitals. |
| Offeror Response |
| 15 |
| The system provides functionality to allow multiple facilities to be defined within the system while supporting each in their unique system options and facility-specific rules. |
| Offeror Response |
| 16 |
| The system provides for "partitions" between two facilities. |
| Offeror Response |
| 17 |
| The successful Bidder provides Help Desk Support for system issues and to immediately resolve technical problems related to use of the system. |
| Offeror Response |
| 18 |
| The system supports LIS and HIS Connectivity, specifically a Cerner Electronic Health Records System. |
| Requirement |
| A.3 |
| The system must be configurable and customizable by authorized users, via development tools provided with the system. |
| Offeror Response |
| A.3 |
| [Offeror must provide a written response in this text box to the requirement above that describes how the requirement will be met, including estimates of the percent: met by the core system, met by the Offeror modifying the core system, or met by CDHS staff modifying the system with the tools provided with the system.] |
| Description |
| 1 |
| The system provides the ability for users to extract information for use in other applications. |
| Description |
| 2 |
| The system supports a report generation process for standard reports that ensures accurate, reliable, and timely reports. |
| Description |
| 3 |
| The system supports the development of custom, ad-hoc reports. |
| Description |
| 4 |
| The system allows users to save both the reports they generate, as well as the report templates they define to create the actual report. |
| Description |
| 5 |
| The system allows users to specify specific standard criteria clauses for compliance, disclosure, legal or financial concerns and/or data classification to be included on a report. |
| Description |
| 6 |
| The system allows the use of a third party report writer to provide ad-hoc reporting capability, e.g. Crystal Reports, Actuate. |
| Description |
| 7 |
| The system allows users to schedule the production of reports to be run on a routine basis, e.g. daily, weekly, monthly or yearly, or at off-peak times. |
| Description |
| 8 |
| The system provides the ability to generate user-defined periodic reports as required by programs/funding organizations, including, but not limited to: |
a. Staff Lockout and Compliance Records
b. Glucometer Login ID Records
c. Test Strip and Reagent Inventory Records
d. Patient History Records
| Description |
| 9 |
| The system provides that clinical alerts and reminders are configurable and can be managed at the facility level. |
| Requirement |
| A.4 |
| The system must provide for maintenance and administration by authorized users. |
| Offeror Response |
| A.4 |
| [Offeror must provide a written response in this text box to the requirement above that describes how the requirement will be met, including estimates of the percent: met by the core system, met by the Offeror modifying the core system, or met by CDHS staff modifying the system with the tools provided with the system.] |
| Description |
| 1 |
| The system provides the tools to access, administer, and manage the data in a standard manner, including, but not limited to: |
Controls for data being imported into the system;
Audit trails on data imported/exported from the system; and Access control (and auditing) at the data item level.
| Description |
| 2 |
| The system supports administrative tools to check and resolve duplicate records, e.g. match and merge functionality. |
| Description |
| 3 |
| The system provides appropriate tools and functionality for establishing metrics and indicators for the quality, completeness and consistency of data. |
| Description |
| 4 |
| The system allows authorized advanced users the use of query tools to access any and all data. |
| Description |
| 5 |
| The system controls access to any saved reports based on the user profile. |
| Description |
| 6 |
| The system allows completed reports to be available online or in storage for a certain timeframe as specified by the State and hospital record retention requirements. |
| Description |
| 7 |
| The system allows for editing of notification groups. |
| Description |
| 8 |
| The system provides user-designated required data fields. |
| Description |
| 9 |
| The system provides the ability to control who can access archived information and specify what information may be accessed. |
| Description |
| 10 |
| The system provides the ability to designate the retention period for a closed record. |
| Description |
| 11 |
| The system provides a method for authorized staff to correct data errors. |
| Description |
| 12 |
| The system documents all error messages. |
| Description |
| 13 |
| The system traps errors from the supporting applications (i.e., database, operating system) and provides a clear explanation as to the source of the error. |
| Description |
| 14 |
| The system identifies submission errors (data that is incomplete or inconsistent with data field requirements). |
| Description |
| 15 |
| The system displays a list of all submission errors, by field for the current screen. |
| Description |
| 16 |
| The system retains properly entered data during the submission error correction process. |
| Description |
| 17 |
| The system identifies errors and provide an editing and validation function to support the correction of any data entry errors. |
| Description |
| 18 |
| The system directs the user to the location where data entry errors occur. |
| Description |
| 19 |
| The system prompts the user when the user attempts to close a window that has unsaved changes. |
| Description |
| 20 |
| The system provides that protocols, formularies, alerts, decision support rules, evidence-based medicine guidelines and other customized information can be selectively shared among users in different facilities to reduce setup time and maximize efficiencies. |
| Requirement |
| A.5 |
| The system must be user-friendly and provide an intuitively-understood interface that is consistent throughout the system, convenient, simple, and supports common computer-based functionality. |
| Offeror Response |
| A.5 |
| [Offeror must provide a written response in this text box to the requirement above that describes how the requirement will be met, including estimates of the percent: met by the core system, met by the Offeror modifying the core system, or met by CDHS staff modifying the system with the tools provided with the system.] |
| Description |
| 1 |
| The system supports utilities similar to Microsoft Office suite of products, e.g. spell check, etc. |
| Description |
| 2 |
| The system supports copying information and pasting from one part of the record into other areas (while also providing for authorized users to disable this function). |
| Description |
| 3 |
| The system supports editing free text files, including basic formatting and spell check. |
| Description |
| 4 |
| The system contains spell-checking functionality for all narrative fields. |
| Description |
| 5 |
| The system provides Copy / Cut / Paste functionality in all narratives (while also providing for authorized users to disable this function for key clinical note and descriptive fields). |
| Description |
| 6 |
| The system notifies the user if another user is concurrently viewing or editing the patient record, and to be able to save their information and provide the ability to reconcile data conflicts. |
| Description |
| 7 |
| The system provides a search engine enabling users to find specific words or phrases in either the free and/or structured text sections of a record. |
| Description |
| 8 |
| The system provides ability to search on any data field. |
| Description |
| 9 |
| The system provides methods to assist an unfamiliar user in querying the database, e.g. through the use of keywords, a natural language or graphical interface. |
| Offeror Response |
| 10 |
| The system allows users to build, document and save queries. |
| Offeror Response |
| 11 |
| The system allows authorized users to access, generate and print reports. |
| Offeror Response |
| 12 |
| The system allows a user to select a standard report, run the report with the default or user-specific parameters, and save the standard report as a template with their preferences. |
| Offeror Response |
| 13 |
| The system allows users to save reports either locally or centrally, route a report electronically, and direct a report to a specific location to be printed. |
| Offeror Response |
| 14 |
| The system allows users to download / export information (e.g., data, report) to their desktop using common file or data formats, e.g., MS Office Word and Excel, ASCII plain text and CSV, and the most current version of Portable Document Format (PDF) as designated by the user and whether the user has access to the information based on their role. |
| Offeror Response |
| 15 |
| The system provides concurrent access to any report created, e.g. more than one person needs to see a report simultaneously. |
| Offeror Response |
| 16 |
| The system allows users to re-direct printing to alternate printers when necessary. |
| Offeror Response |
| 17 |
| The system provides easy import and export of data. |
| Offeror Response |
| 18 |
| The system prevents users from entering invalid information, e.g. mechanisms can include pick list, field formatting, and rules on field entry triggered by field exit. |
| Offeror Response |
| 19 |
| The system provides word processing functionality for text fields. |
| Offeror Response |
| 20 |
| The system provides both online help and context-sensitive help. |
| Offeror Response |
| 21 |
| The system provides a user interface that is compliant with American Disability Act (i.e., Section 508 compliant). |
| Offeror Response |
| 22 |
| The system allows users to personalize their workspace, such as preferences for layout, navigation and the use of tools appropriate to his/her workflow. |
| Offeror Response |
| 23 |
| The system provides an easily viewed navigational structure that allows users to know where they are at all times and can easily return them to a desired starting point. |
| Offeror Response |
| 24 |
| The system provides a unique name for each screen. |
| Offeror Response |
| 25 |
| The system displays the screen name at all times. |
| Offeror Response |
| 26 |
| The system places the screen name(s) in a consistent location. |
| Offeror Response |
| 27 |
| The system provides navigational links to related screens. |
| Offeror Response |
| 28 |
| The system provides access to the home page and logout from anywhere within the system. |
| Offeror Response |
| 29 |
| The system provides quick access and retrieval (Less than 2 seconds response time or better). Please see the related CDHS Bandwidth Diagram (Appendix B) and describe how the system will meet this requirement within the CDHS network infrastructure configuration and bandwidth speeds. |
| Requirement |
| A.6 |
| The system must provide for the creation and support of clinical workflow development and management. |
| Offeror Response |
| A.6 |
| [Offeror must provide a written response in this text box to the requirement above that describes how the requirement will be met, including estimates of the percent: met by the core system, met by the Offeror modifying the core system, or met by CDHS staff modifying the system with the tools provided with the system.] |
| Description |
| 1 |
| The system provides tools for workflow development and management to support hospital business processes, both clinical and administrative. |
| Description |
| 2 |
| The system allows user-defined rules regarding alerts. |
| Description |
| 3 |
| The system allows a user to delegate an approval process to another authorized user for a specified period of time. |
| Description |
| 4 |
| The system provides workflow that implements an approval hierarchy based on the hospital authorization rules for that business process. |
| Description |
| 5 |
| The system attaches electronic signature(s) to indicate authorization or approval in accordance with the needs of a given business process/workflow. |
| Requirement |
| A.7 |
| The system must provide for the creation, support, and transfer of secured patient records from glucometer to EHR |
| Offeror Response |
| A.7 |
| [Offeror must provide a written response in this text box to the requirement above that describes how the requirement will be met, including estimates of the percent: met by the core system, met by the Offeror modifying the core system, or met by CDHS staff modifying the system with the tools provided with the system.] |
| Description |
| 1 |
| The system contains and transfers the following information for each glucose test performed: |
| Description |
| 2 |
| Unique Medical Record ID |
| Description |
| 3 |
| Unique Patient ID |
| Description |
| 4 |
| Unique Barcode information (if results are scanned) |
| Description |
| 5 |
| Patient last name |
| Description |
| 6 |
| Patient first name |
| Description |
| 7 |
| Patient birthdate |
| Description |
| 8 |
| Patient gender |
| Description |
| 9 |
| ID of glucometer operator |
| Description |
| 10 |
| ID of glucometer |
| Description |
| 11 |
| Unique ID of sample tested |
| Description |
| 12 |
| Test strip information |
| Description |
| 13 |
| Date sample test performed |
| Description |
| 14 |
| Result for sample tested |
| Description |
| 15 |
| Notes concerning sample—may come from the glucometer at testing or from lab staff entry using web-based client access to the data |
| Requirement |
| A.8 |
| The system must provide audit trails and reports, as well as the ability for authorized users to construct audits of any actions or values in any field, table or processing function (such as printing, viewing, saving, editing, deleting, etc.). |
| Offeror Response |
| A.8 |
| [Offeror must provide a written response in this text box to the requirement above that describes how the requirement will be met, including estimates of the percent: met by the core system, met by the Offeror modifying the core system, or met by CDHS staff modifying the system with the tools provided with the system.] |
| Description |
| 1 |
| The system provides auditing capability customizable down to data field level, e.g. select the data elements to be audited and the detail of information returned by the audit. |
| 2 |
| The system provides a complete audit trail for all datasets so discrepancies between different datasets can be evaluated and explained. Audit capabilities include, but are not limited to, tracking: |
Identity of person accessing the information, e.g. user ID Actions taken on data, e.g. read, write, update, delete or print Date/time when the information was accessed Location from where the access was requested, e.g. on-grounds or remotely
| 3 |
| The system maintains an accessible audit trail of all error corrections. |
| 4 |
| The system provides "strike-out" ability for correction of errors in charting entries. |
| 5 |
| The system allows for corrections made with a "red line" or similar feature - to clearly identify the error as well as by the date/time and author. |
| 6 |
| The system requires an electronic signature, date, and time when an error correction is made. |
| 7 |
| The system provides the ability to modify documentation entered in error, maintaining a record of the original entry, identification of the clinician correcting the error and the date and time corrected. |
| Requirement |
| A.9 |
| The system provides a data-archival and retrieval function. |
| A.9 |
| [Offeror must provide a written response in this text box to the requirement above that describes how the requirement will be met.] |
| Description |
| 1 |
| The state would prefer the system to include data archival functionality. This archive process ensures data confidentiality, availability, accessibility and integrity for the life of the system. |
| Description |
| 2 |
| The system provides the ability to retain patient data within the database until otherwise purged, deleted, archived, or otherwise deliberately used. |
| Section |
| B |
| Security Requirements |
| Requirement |
| B.1 |
| The system must provide secure user identification. |
| Offeror Response |
| B.1 |
| [Offeror must provide a written response in this text box to the requirement above that describes how the requirement will be met, including estimates of the percent: met by the core system, met by the Offeror modifying the core system, or met by CDHS staff modifying the system with the tools provided with the system.] |
| Description |
| 1 |
| The system locks user accounts after three failed log-in attempts. Locked accounts are enabled by the system Administrator. |
| Description |
| 2 |
| The system requires that a unique user name and password be assigned to every user of the system. |
| Description |
| 3 |
| The system contains the following information for each user: |
| Description |
| 4 |
| Unique User ID |
| Description |
| 5 |
| Employee ID (EID – if it exists within the system) |
| Description |
| 8 |
| Agency (State or County Name) |
| Description |
| 9 |
| ID Creation Date |
| Description |
| 10 |
| Last Login Date |
| Description |
| 11 |
| Last Password Change Date |
| Description |
| 12 |
| Access Rights (profile) |
| Description |
| 13 |
| Indication if the ID is a system, user, admin or shared ID (note: shared ID will show an approval stamp from the Department’s HIPAA Privacy and Security Officer). |
| Requirement |
| B.2 |
| The system must provide comprehensive, role-based, user access functionality within the database. |
| Offeror Response |
| B.2 |
| [Offeror must provide a written response in this text box to the requirement above that describes how the requirement will be met, including estimates of the percent: met by the core system, met by the Offeror modifying the core system, or met by CDHS staff modifying the system with the tools provided with the system.] |
| Description |
| 1 |
| The system allows only authorized users, as defined by roles / access rights, to change or delete data within the system. |
| Description |
| 2 |
| The system allows for multiple user-defined security profiles using the ‘Role Based Access Control’ (RBAC) standard. |
| Description |
| 3 |
| Security profiles must have defined access rights that follow rules for which system functions and data may be accessed and updated. |
| Description |
| 4 |
| Security profiles must be easy to use and easy to maintain. |
| Description |
| 5 |
| Each system security profile allows for a mix of user-defined read / write / execute / delete access permissions. |
| Description |
| 6 |
| Number of login attempts since last successful login |
| Description |
| 7 |
| Number of failed login attempts since last successful login |
| Description |
| 8 |
| The system logs the following information specific to user access within the database: |
| Description |
| 9 |
| The system assigns a unique date, time, and user stamp on all saved records; |
| Description |
| 10 |
| The accessed information(identified by individual data elements); |
| Description |
| 11 |
| The action taken (e.g., viewed, updated, printed); |
| Description |
| 12 |
| Who accessed the information |
| Description |
| 13 |
| When the information was accessed (e.g., date and time) |
| Description |
| 14 |
| The system must be capable of reporting an Audit Trail of Access; and |
| 15 |
| The system must protect the audit log files used to track the above information from unauthorized access. |
| Description |
| 16 |
| The system must retain audit log files for 6 years |
| Requirement |
| B.3 |
| The system must provide controls for role-based, security-restrained user access functionality to associated glucometers. |
| Offeror Response |
| B.3 |
| [Offeror must provide a written response in this text box to the requirement above that describes how the requirement will be met, including estimates of the percent: met by the core system, met by the Offeror modifying the core system, or met by CDHS staff modifying the system with the tools provided with the system.] |
| Description |
| 1 |
| The system allows only authorized users, as defined by roles / access rights, to change or delete data within the system. |
| Description |
| 2 |
| Security profiles must have defined access rights that follow rules for which system functions and data may be accessed and updated. Security profiles must be easy to use and easy to maintain. |
| Description |
| 3 |
| Each system security profile allows for a mix of user-defined access permissions. |
| Description |
| 4 |
| Access to glucometers is restricted by staff certification, with certification records maintained within the system database. |
| Requirement |
| B.4 |
| The Successful Offeror must comply with all relevant state and federal rules, regulations, and policies in regards to system and data security, including those for HIPAA and Code of Federal Regulations (CFR) 42. |
| Offeror Response |
| B.4 |
| [Offeror must provide a written response in this text box to the requirement above that describes how the requirement will be met, including estimates of the percent: met by the core system, met by the Offeror modifying the core system, or met by CDHS staff modifying the system with the tools provided with the system.] |
| Description |
| 1 |
| The successful Offeror complies with all security rules and policies issued by the Colorado Office of Information Security found at: http://www.colorado.gov/cs/Satellite/OIT-Cyber/CBON/1251575408771. Specific requirements include the following: |
| Description |
| 2 |
| Offeror shall provide documentation of all support tools/diagnostic software to be used within the OIT network |
| Description |
| 3 |
| Offeror shall provide a diagram of proposed network communications between and MHI locations (based on CDHS Bandwidth Diagram Appendix B) |
| 4 |
| If proposing a Hosted system, Offeror shall provide a diagram of network communications between , MHI locations, and the Host system (based on CDHS Bandwidth Diagram Appendix B.) |
| Description |
| 5 |
| Offeror shall provide documentation of all proposed protocols to be used within the MHI Glucometer System |
| Description |
| 6 |
| Offeror shall provide documentation of all proposed third-party applications to be used within the MHI Glucometer System |