Copy of Att 6 Requirements Matrix.xlsx
XLSX spreadsheet 111 KB Posted
- Attached to
- 22EHSLCe-CASRFR: Request for Responses for the EHS Comprehensive Assessment System Vendor
- Solicitation number
- BD-22-1039-EHS01-EHS01-70914
- Issued by
- Suffolk County, Massachusetts
About this file
This document is a Request for Responses (RFR) issued by the Massachusetts Executive Office of Health and Human Services (EOHHS) for the purposes of procuring a qualified vendor to implement, maintain, and support a software solution for digitized clinical assessments and workflows for certain MassHealth long-term services and supports and behavioral health programs, with potential expansion to include other MassHealth programs. The requested solution, referred to as the EHS Comprehensive Assessment System (e-CAS), will serve as a centralized repository for all assessments and provide functionality for data exchange, assessment workflows, quality reviews, appeals, and user management. The RFR outlines detailed requirements across areas such as general system, data exchange, assessment tools, referrals, quality review, and appeals.
The RFR does not provide specific pricing terms or set-asides, but indicates the state seeks to procure these services through a competitive process. It does not mention any incumbent vendors. The RFR states the e-CAS solution will need to integrate with various EOHHS systems, including the Medicaid Management Information System (MMIS), Master Data Management (MDM) system, and other interfaces. Funding for this project will come from EOHHS, but the document does not specify the budget amount.
View the file
Other files
Show all 18
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
Instructions
EHS Comprehensive Assessment System (e-CAS) RFR, Attachment 6, EOHHS Requirements
| INSTRUCTIONS FOR COMPLETING THE REQUIREMENTS MATRIX |
| For each requirement listed in the Main worksheet, Bidders will populate with an "x" |
| one of the following columns - L, M, N, or O - based on how its proposed solution meets |
| that requirement. |
| For purposes of determining how to populate these columns, Bidders will apply |
| the following definitions: |
| - Configuration: a software application’s features or behavior can be changed through the use of functionality, tools and/or utilities native to/built into the software application, i.e. without the need for custom programming/coding. |
- Customization: a feature, extension or modification of a software application’s feature that requires custom programming/coding.
| Bidders are encouraged to make use of Column P - EXPLANATION/ELABORATION - |
| to provide as much detail as deemed appropriate on how the proposed solution meets, |
| or does not meet, a particular requirement. |
Acronyms Key
EHS Comprehensive Assessment System (e-CAS) RFR, Attachment 6, EOHHS Requirements
| ACRONYMS USED IN THE ATTACHMENT | |
| Mgt | Management requirement |
| F | Functional requirement |
| Tech | Technical requirement |
| Spec | Specification detail |
| LCM | Lifecycle management |
Req Matrix Response EHS Comprehensive Assessment System (e-CAS) RFR, Attachment 6, EOHHS Requirements Check ("x") the box below which correspond to how the proposed solution meets a particular requirement. For purposes of completing this exercise, the following definitions apply:
- Configuration: a software application’s features or behavior can be changed through the use of functionality, tools and/or utilities native to/built into the software application, i.e. without the need for custom programming/coding.
| - Customization: a feature, extension or modification of a software application’s feature that requires custom programming/coding. | In this column, elaborate as deemed appropriate on how the proposed solution meets a particular requirement OR why the proposal does not include functionality that meets that requirement. | HIDE | HIDE | HIDE | HIDE | ||||
| 1 | 0.8 | 0.5 | 0 |
| Requirement Areas | BIDDER RESPONSE TO REQUIREMENT | Rating: | RAW | % RAW | ADJ | |||||||||||||||||||
| Module ID | Ref # | Module | Feature | Category | Requirement Statement | Mgt | F | Tech | Meets Requirement “Out of the Box” - No Configuration Needed | Meets Requirement - Configuration Needed | Only Meets Requirement via Customization | Does Not Provide Required Functionality | EXPLANATION/ | |||||||||||
| ELABORATION | 0.00 | ERROR:#DIV/0! | ERROR:#DIV/0! | |||||||||||||||||||||
| GS | 1 | General System | Exception/Error Handling | Data Exchange | Follow existing standards and protocols for exception/error handling during data exchange processes. If no standard exists, develop reasonable, clear protocols for handling exceptions/errors during data exchange processes. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 2 | General System | Exception/Error Handling | System Architecture | Facilitate development of programmatic rules related to exception/error handling. Includes discussing business rules with EOHHS staff and selected staff from parties with whom data is being exchanged, providing guidance on how best to achieve business needs, and developing solutions to support business needs. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 3 | General System | System Logs/Change History | Security | Engage in extensive technical systems logging in order to facilitate troubleshooting. In particular, developers should be able to engage in root cause analysis to diagnose problems and develop solutions to urgent problems within timeframes set forth in Attachment 5, Key Performance Indicators. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 4 | General System | System Logs/Change History | Business Continuity and Disaster Recovery | Ensure e-CAS data can be recovered quickly in the event of a systems issue. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 5 | General System | System Logs/Change History | Audit | Ensure vendor’s technical support and help desk vendor staff can access adequate history of system logs/change history in order to facilitate problem-solving with e-CAS end users. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 6 | General System | System Logs/Change History | Audit | Ensure adequate system logging/change history, and provide system logs to end users as necessary (e.g., to facilitate resolution of Help Desk ticket). | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 7 | General System | System Logs/Change History | Audit | Be able to provide history of users' history of searches, accessing assessments, and downloads to assist with auditing in the case of fraud, waste, or abuse. | |||||||||||||||||||
| GS | 8 | General System | Upgrades | System LCM | Implement technical upgrades to the e-CAS to ensure optimal functioning and compliance with system requirements. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 9 | General System | Continuity of Operations | Business Continuity and Disaster Recovery | Meet continuity of operations requirements, including industry standards for security and disaster recovery, and the requirements found at 45 CFR 205.50; 45 CFR, Subpart F, §§ 95.601-95.64. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 10 | General System | Accessibility | Accessibility Management | Ensure accessibility requirements, specifically that any software developed for or provided to EOHHS for the e-CAS adheres to the standards of Section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. § 794(d)), and will comply with the EOHHS Virtual Gateway and Massachusetts web accessibility policies. The web accessibility standards checklist (available at the Massachusetts Office of Information Technology website) shall be delivered with each software delivery or build, and any updates, new releases or modifications to the software (“Enhancements”). In addition, the vendor shall ensure that all software and Enhancements meet the standards of the “Bobby Worldwide” diagnostic tool, and work effectively with “JAWS” software. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 11 | General System | Member Management | Member Info Mgt | Maintain a master Member record such that [1] there are no duplicate Members in the e-CAS, [2] all native e-CAS assessments and forms, select imported information (e.g. Member information captured in the MMIS), documents and metadata are part of the record and updated based on rules (e.g. hierarchy that treats certain Member data in the MMIS as authoritative), [3] the Member record is interfaced as applicable to the EOHHS Master Data Management (MDM) system, [4] multiple attributes about a Member (e.g. unique IDs from multiple source systems, addresses and other contact information from multiple source systems) can be stored in the master record and [5] for a Member “linking” process, effectively combine Member information, do not lose any data, associate information with an active MMIS system ID, and de-activate old IDs/Member profiles. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 12 | General System | Member Management | Member Info Mgt | Make all master record information accessible in a Member search, subject to any user-specific limitations. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 13 | General System | Member Management | Member Info Mgt | Engage in processes to prevent duplication of Member records. This includes but is not limited to: | |||||||||||||||||||
| • | Utilizing the MDM | |||||||||||||||||||||||
| • | Utilizing any other relevant Member matching System Logic or processes recommended by vendor | |||||||||||||||||||||||
| • | Having post-hoc Member “linking” process to resolve any instances where duplicate Member records are combined. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||||||
| GS | 14 | General System | Member Management | Member Info Mgt | Automatically redirect searches for an inactive Member ID/profile to the active ID/profile. | X | 0 | 0 | 0 | 0 | 0 | Ch | ||||||||||||
| GS | 15 | General System | Member Management | Member Info Mgt | Provide notification to users who have an in-process assessment or other form that the Member’s profile has been “linked” and has a new active ID. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 16 | General System | Member Management | Member Info Mgt | Cancel in-process assessments or other forms for the inactive Member profile. Provide notice to user that this will occur. Allow user to copy cancelled assessments and move data from cancelled assessment to the assessment associated with the active Member profile. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 17 | General System | Single-Sign On | Accessibility Management | Support single sign on to facilitate ease of access for users. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 18 | General System | General | System Architecture | Provide non-production system environment(s) for development and user acceptance testing (UAT), and other non-production system environments as needed. Specifically, the e-CAS must contain at least three distinct environments: Production, Pre-Production/Staging, and a User Acceptance Testing (UAT)/Testing environment. The pre-production stage should be an exact mirror of production, including data, infrastructure, and access. The UAT environment should mirror access capabilities. The expectation is that all testing will occur in the UAT environment, be verified in pre-production, and sent to production without the need for further testing. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 19 | General System | General | System Architecture | The e-CAS shall be compliant with Google Chrome, Firefox and Internet Explorer browsers (latest version) at time of production deployment, and ensure updated compatibility with any major browser updates. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 20 | General System | General | System Architecture | The e-CAS must be compatible with web services protocols. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 21 | General System | General | Accessibility Management | All database data will be accessible 24/7 by EOHHS users. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 22 | CRM | Help Desk/Support | Help Desk/Support | Vendor will supply and maintain a system for secure request of end user support, reporting of end user functionality and technical problems submitted to the vendor for investigation and resolution, and tracking and reporting the status of end user support requests and reported problems. The system will also support triaging and prioritization of requests and reported problems, routing of requests and reported problems to different individuals/teams, and access to "answers to frequently asked questions" and other information which end users can use. | |||||||||||||||||||
| Note: EOHHS plans to use its existing help desk vendors servicing Provider and Member calls to triage e-CAS customer service calls, address what they can, and then route requests to the e-CAS vendor that they are unable to resolve. The help desk vendors will also help triage and resolve, when possible, end user requests submitted through the e-CAS for investigation and resolution. Therefore, the system to track and report problems will be used by both EOHHS and the help desk vendors. | X | 0 | 0 | 0 | 0 | 0 | ||||||||||||||||||
| GS | 23 | CRM | Help Desk/Support | Help Desk/Support | Provide viewable real-time assessment information to help desk staff and other users from EOHHS partner vendors or state agencies. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 24 | CRM | Help Desk/Support | Help Desk/Support | Produce and make available to users a set of Frequently Asked Questions. The vendor will collaborate with the help desk vendors to update content over time based on common questions. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 25 | CRM | Help Desk/Support | Help Desk/Support | Produce and maintain system user guides and training materials. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 26 | CRM | Help Desk/Support | Help Desk/Support | Conduct train the trainer training sessions on the system for EOHHS staff, help desk staff and others who use the system. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 27 | CRM | Help Desk/Support | Help Desk/Support | Make staff available for speaking to help desk staff for case resolution of escalated, special circumstances or complex cases. In rare and complex cases, make the appropriate staff available for speaking to users for case resolution when a help desk representative could bring a support representative on the call to assist the user with issue resolution. | X | 0 | 0 | 0 | 0 | 0 | Ch | ||||||||||||
| GS | 28 | CRM | Noticing – General | Noticing | Generate paper and electronic notices that will be sent to communicate various updates and outcomes produced by users within the e-CAS. Notices may be sent to Members and authorized representatives, referral sources/entities, Health Plans, LTSS or BH Providers, and other health care Providers, such as PCPs. Notices may be include UCA System Logic Outputs, TTT Outputs, and other pertinent data. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 29 | CRM | Noticing – General | Noticing | Create and maintain notice templates in collaboration with EOHHS staff, manage changes and version control of these templates, enable EOHHS staff to make changes through configuration of standard notice components (e.g. salutation, introduction, etc.) and add new notices over time. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 30 | CRM | Noticing – General | Noticing | Generate notice templates in a minimum of English and Spanish and other prevalent languages as required by EOHHS. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 31 | CRM | Noticing – General | Noticing | Generate a timely PDF of notices on the same or next business day as the business event that triggered the notice. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 32 | CRM | Noticing – General | Noticing | Suppress notice generation according to data-driven rules or manually by certain users. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 33 | CRM | Noticing – General | Noticing | Allow users to trigger generation of a duplicate notice upon request. For example, help desk staff users should be able to trigger an additional copy of a notice to be sent in response to end user request. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 34 | CRM | Noticing – General | Quality Mgt | Conduct quality checks of notices before they are sent, and have a process for correcting notices that did not pass the quality review. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 35 | CRM | Noticing – General | Noticing | Include Appeal Form in templates for notices that have Appeal rights. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 36 | CRM | Noticing – General | Noticing | Include Babel Sheet in all templates. The Babel Sheet includes information in multiple languages that tells the reader that the notice is important and what they can do to get the notice translated. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 37 | CRM | Noticing – General | Noticing | Be able to add messages and inserts to notices that are different based on triggers such as Members with high-risk eligibility outcomes (e.g., Members whose re-evaluations determine that they are no longer eligible for their current program(s). | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 38 | CRM | Noticing – MMIS | Data Exchange | Interface with MMIS web service to send necessary notice information, including list of notices to be sent and attachments with actual notices (i.e., with Member and assessment information autopopulated into the standard template). | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| GS | 39 | General e-CAS | General | Security | Provide confidential and sensitive data with data encryption that covers data at rest (whether on the database or on backups) and in motion /transit (over the network). Types of data that require protection include (but is not limited to) Personally Identifiable Information (PII). | X | ||||||||||||||||||
| DE | 40 | Data Exchange | General | Data Exchange | Provide multiple secure options for data exchange, including FTP and API. EOHHS has a preference for API-based exchanges; however, vendor must be able to offer alternative solutions based on needs of other parties. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| DE | 41 | Data Exchange | General | Data Exchange | Allow for call/response integration from certain database systems, such as the MassHealth Data Warehouse and the UMCMS CANS Training & Certification system. The purpose is to enable as needed/ad hoc real-time data exchange, where the recipient system requests data that the e-CAS then provides. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| DE | 42 | Data Exchange | General | System LCM | Maintain and perform periodic updates to all system components and associated interfaces to ensure continued high performance; maintain a change management process and system such that these updates are recorded and handled in a manner that minimizes end user disruption and system unavailability. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| DE | 43 | Data Exchange | General | System Architecture | Create data exchange functionality in a way that allows for the evolution of data exchange needs, i.e., the system architecture should be designed so that the e-CAS can be flexible to accommodate additional interfaces with new parties, different types of exchange methodologies, and updates to data exchanged or exchange processes in an efficient and cost-effective manner. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| DE | 44 | Data Exchange | MassHealth Data Warehouse | Data Exchange | Send regular (i.e., up to daily or real-time) data downloads to the MassHealth Data Warehouse following formats/layouts and data exchange protocols that are prescribed by MassHealth. Data that will be sent to the Data Warehouse includes but is not limited to: CANS tool, UCA tool, Time-to-Task (TTT) tool, referral form and other pertinent documents, System Logic Outputs, assessment status information, Member information and Assessor information. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| DE | 45 | Data Exchange | Master Data Management System (MDM) | Data Exchange | Receive and incorporate Member data from the MDM. The purpose of data exchange from MDM to UCA: |
· Ensure e-CAS maintains a master Member record that is unduplicated.
| · Intake EOHHS agency data that may be important to the e-CAS functioning (e.g., EOEA waiver enrollment, DDS waiver enrollment, MRC waiver enrollment, DMH program enrollments). | X | 0 | 0 | 0 | 0 | 0 | |||||||||||
| DE | 46 | Data Exchange | Master Data Management System (MDM) | Data Exchange | Return data to the MDM. The purpose of data exchange from e-CAS to MDM: | ||||||||||||
| · Share high-level e-CAS information that may be useful for EOHHS agencies to access (e.g., date of last assessment, service qualifications). | X | 0 | 0 | 0 | 0 | 0 | |||||||||||
| DE | 47 | Data Exchange | MDS-HC2 Application | Data Exchange | Intake historical upload(s) of MDS-HC2 data in order to ensure the complete history of available MDS-HC2 assessments is stored in the e-CAS database. Allow uploaded data to be used the same as data entered directly into the e-CAS. | X | 0 | 0 | 0 | 0 | 0 | ||||||
| DE | 48 | Data Exchange | CANS Application | Data Exchange | Intake historical upload(s) of CANS data in order to ensure the complete history of available CANS assessments is stored in the e-CAS database. Allow uploaded data to be used the same as data entered directly into the e-CAS. | X | |||||||||||
| DE | 49 | Data Exchange | Medicaid Management Information System (MMIS) | Data Exchange | Intake data from MMIS on a regular basis, including but not limited to: |
· Daily standardized Member file
· Standardized Provider file
· Prior Authorization (PA) file
| · MMIS claims file | X | 0 | 0 | 0 | 0 | 0 | ||||||||||||||
| DE | 50 | Data Exchange | Medicaid Management Information System (MMIS) | Data Exchange | Send necessary e-CAS data to MMIS. Work with MMIS to develop standardized file that MMIS can intake including but not limited to relevant e-CAS data, such as System Logic Outputs, level of service units, Rating Categories, PDFs or attachments of full Assessment Tools. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| DE | 51 | Data Exchange | Senior Information Management System (SIMS) | UCA Tool | Receive CDS-3 assessment data from SIMS, including full assessments, other documents and attachments. Clean and normalize data and allow CDS-3 data to be used the same as data entered directly into the e-CAS. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| DE | 52 | Data Exchange | Senior Information Management System (SIMS) | UCA Tool | Share UCA assessment data with SIMS, including but not limited to full UCA assessments or other documents, attachments, System Logic outcomes, summary or metadata about assessments. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| DE | 53 | Data Exchange | Senior Information Management System (SIMS) | UCA Tool | Provide data to and receive data from SIMS following formats/layouts and data exchange protocols that are prescribed by EOHHS. Ensure standardization of data exchange with SIMS through proper documentation and controls. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| DE | 54 | Data Exchange | Optum Long-Term Services and Supports Management System (LTMS) | UCA Tool | Send LTMS standardized daily data feed using formats prescribed by EOHHS, which may include but is not limited to: | |||||||||||||||
| • | UCA tool | |||||||||||||||||||
| • | TTT tool | |||||||||||||||||||
| • | Other documents, such as Referral Form | |||||||||||||||||||
| • | System Logic Outputs | |||||||||||||||||||
| • | Assessment status information | |||||||||||||||||||
| • | Member information | |||||||||||||||||||
| • | Assessor information | |||||||||||||||||||
| • | Attachments | X | 0 | 0 | 0 | 0 | 0 | |||||||||||||
| DE | 55 | Data Exchange | MA-21 | Data Exchange | Send necessary e-CAS data to MA-21. Work with MA-21 to develop standardized file that MA-21 can intake, including but not limited to relevant e-CAS data, such as System Logic Outputs, Rating Categories, PDFs or attachments of full Assessment Tools. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| DE | 56 | Data Exchange | EDMC | Data Exchange | Send necessary e-CAS data to EDMC. Work with MassHealth to develop standardized file that EDMC can intake, including but not limited to relevant e-CAS data, such as Member clinical eligibility decision notice data or PDFs. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| DE | 57 | Data Exchange | Center for Medicare & Medicaid Services (CMS) Data Exchange | Data Exchange | Receive monthly downloads of CMS assessment data, including OASIS and MDS-HC, in the format/layout utilized by CMS | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| DE | 58 | Data Exchange | Center for Medicare & Medicaid Services (CMS) Data Exchange | Data Exchange | Incorporate CMS assessment data into the e-CAS database for analysis along with other assessments for Members with assessments in the e-CAS database. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| DE | 59 | Data Exchange | Providers and Plans | Data Exchange | In order to support Providers and Health Plans in the assessment process, share e-CAS data with Providers and Health Plans (i.e., Trading Partners). Data shared may include but is not limited to full assessments or other documents, attachments, System Logic Outputs, summary or metadata about assessments. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| DE | 60 | Data Exchange | Providers and Plans | Data Exchange | In order to allow some EOHHS agencies, Providers and/or Health Plans to perform assessments within their own systems, receive e-CAS Assessment Tool data from Trading Partners and EOHHS systems, including but not limited to full assessments or other documents and attachments. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| DE | 61 | Data Exchange | Providers and Plans | Data Exchange | Incorporate this information into the e-CAS database and allow it to be used the same as data entered directly into the e-CAS. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 62 | Assessment Tools | Mapping Tools | UCA Tool | Because the e-CAS is intended to be a centralized repository of all LTSS assessments, Vendor must maintain within its systems a mapping of the UCA to other LTSS assessments including but not limited to the MDS-HC2, CDS-3 and TTT. EOHHS will provide question/answer-level requirements for mapping. Vendor is responsible for ensuring questions/answers are properly mapped between tools, and for making any updates to mapping over time. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 63 | Assessment Tools | Mapping Tools | CANS Tool | Because the e-CAS is intended to be a centralized repository of all CANS assessments, Vendor must maintain within its systems a mapping of the CANS held within the e-CAS to other versions of the CANS that are held in other EOHHS systems (ex. DCF CANS with supplementary questions). EOHHS will provide question/answer-level requirements for mapping. Vendor is responsible for ensuring questions/answers are properly mapped between tools, and for making any updates to mapping over time. | X | ||||||||||||||
| AT | 64 | Assessment Tools | Mapping Tools | Assessment functionality | Create, maintain, store and retain version details of mapped tools in a tools repository, manage changes and version control of these tools, and enable EOHHS staff to make said changes through configuration of standard/reusable tool components. For purposes of this requirement, version details include: | |||||||||||||||
| Maintain labelling and naming conventions to ensure that every change in a question/answer (including but not limited to editing questions/answers, adding/deleting questions/answers, re-ordering of questions/answers, etc.) is clearly recorded and results in a new Assessment Tool version. Significant changes may be labelled with a new whole number (e.g., going from UCA 1.0 to UCA 2.0); minor changes may be labelled with a new decimal point (e.g., going from CANS 1.0 to 1.1) | X | 0 | 0 | 0 | 0 | 0 | ||||||||||||||
| AT | 65 | Assessment Tools | Mapping Tools | System LCM | As the mapping of assessment tools requires clinical input from EOHHS staff, Vendor provides project management within established change management procedures to support mapping updates. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 66 | Assessment Tools | Version Control | Assessment functionality | Notify all e-CAS users of Assessment Tool version changes, with a clear/easy to understand summary of what has changed and what impact it will have on different user types and programs, and clearly document and display version of the tool to end-users and in all user-facing reports. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 67 | Assessment Tools | Version Control | Assessment functionality | When a new version of an Assessment Tool is released, the following updates to “in process” assessments or other native Assessment Tools will be made: |
• Convert questions that have been mapped from an old to a new version into the new version of the question.
• Mark questions that are on the old version but not the new version as “inactive” and do not allow further changes to be made.
• Add questions that are on the new version but not the old version. Modify questions that have been modified.
• If the answer already completed in the assessment applies to the new question, keep the answer.
• If the answer already in there does not apply, answer disappears (e.g., a question changed from free text to multiple choice would not retain an answer; a multiple-choice question where the answer choice is no longer available would not retain an answer).
| • Perform any re-ordering or re-grouping of questions/answers or sections. | X | 0 | 0 | 0 | 0 | 0 | ||||||||||||||
| AT | 68 | Assessment Tools | Version Control | Assessment functionality | When a new version of an Assessment Tool is released, all new assessments that are created will be the updated version. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 69 | Assessment Tools | Questions Configurability | Assessment functionality | Enable configuration of Assessment Tools and System Logic by Vendor or designated EOHHS staff; configuration changes may include adding/deleting or modifying questions/answers and/or question types, changing skip logic and dependent questions, Linked Questions and question groupings (into "modules"), changing the order of questions within or across modules, auto-population of certain fields, and mandatory question rules. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 70 | Assessment Tools | Questions Configurability | Assessment functionality | Within each Assessment Tool, enable configurability of questions based on the reason for assessment being created (e.g., New Intake, Status Change Update, Annual Re-Assessment). | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 71 | Assessment Tools | Questions Configurability | Assessment functionality | Within each Assessment Tool, enable configurability of questions based on the MassHealth Program/Service for which a Member is being assessed (e.g., Member is enrolled with a Senior Care Options plan or is receiving Personal Care Attendant (PCA) services at the time of the assessment). | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 72 | Assessment Tools | Questions Configurability | System LCM | Maintain a Change Control Process for all Assessment Tool changes, including but not limited to changes in question or System Logic logic, sequencing, and additions/deletions. Changes must be implemented in a timely manner established by mutual agreement of EOHHS and vendor. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 73 | Assessment Tools | Questions Configurability | TTT Tool | In addition to normal configurability rules, many TTT questions have recommended “ranges” for episodes, days, and minutes based on the level of assist needed per ADL. These ranges will also need to be configurable; ranges should be viewable for each episode/days/minutes question. Users may enter data that is outside of the recommended “range”. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 74 | Assessment Tools | Questions Logic | Assessment functionality | Develop and maintain logic whereby questions and answers are dynamically displayed and support easy navigation through the Assessment Tool. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 75 | Assessment Tools | Questions Logic | Assessment functionality | Enable, maintain, and allow updates to logic for display of questions based on business rules logic that indicates what questions to display or not based on certain answers to questions. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 76 | Assessment Tools | Questions Logic | Assessment functionality | Enable, maintain, and allow updates to logic linking questions within a section or across sections (e.g., link a particular treatment and diagnosis such as radiation and cancer). | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 77 | Assessment Tools | Questions Logic | Assessment functionality | Develop, enable, maintain, and allow updates to autopopulation logic based on rules developed in collaboration with EOHHS (e.g., allow assessment Engagement Date to be provided by user each time a new assessment is initiated. The date will not update if user takes multiple visits to complete the assessment but will update after assessment has been completed and a new one is started). | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 78 | Assessment Tools | Questions Logic | Assessment functionality | Enable, maintain, and allow updates to logic that allows for the autopopulation of certain fields using the most recent prior assessment data (e.g., from the UCA or other mapped assessments including MDS-HC2, CDS-3, and TTT) and data from MMIS. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 79 | Assessment Tools | Questions Logic | Assessment functionality | Enable, maintain, and allow updates to logic that allows for the autopopulation of certain historical data and prompts users to update data (e.g., diagnoses or medication history autopopulated from prior assessment but users prompted to confirm changes since last assessment or confirm no updates). | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 80 | Assessment Tools | Questions Logic | Assessment functionality | Enable, maintain, and allow updates to logic conducting validity checks on answers and providing messages when not valid (e.g., if an invalid MassHealth ID number is provided, notify the user to fix the number). | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 81 | Assessment Tools | Questions Logic | Assessment functionality | Enable, maintain, and allow updates to logic allowing users to update certain autopopulated Member data, such as phone and address data, and providing messages to prompt user to take an action outside of the assessment process to update these data with MassHealth. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 82 | Assessment Tools | Questions Logic | Assessment functionality | Enable, maintain, and allow updates to logic displaying responses in multiple ways (drop down, select all that apply, text box, radio button, etc.). | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 83 | Assessment Tools | Questions Logic | Assessment functionality | Enable, maintain, and allow updates to logic allowing users to quickly navigate through questions using keyboard actions (e.g., use arrows or tabs to move from question to question or use first letter of a response (e.g., "Y" for "Yes")). | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 84 | Assessment Tools | Questions Logic | Assessment functionality | Enable, maintain, and allow updates to logic that allows users to provide a series of answers, which can then be prioritized and categorized. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 85 | Assessment Tools | Questions Logic | Assessment functionality | Enable, maintain, and allow updates to logic that leads to the auto-expansion of options for questions requiring multiple discreet answers (e.g., for a question asking for the Member’s personal goals, automatically add an option for the next goal once the current goal is completed). | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 86 | Assessment Tools | Questions Logic | Assessment functionality | Enable, maintain, and allow updates to logic that checks for proof of spelling and grammar on user’s free text. | X | 0 | 0 | 0 | 0 | 0 | Intf | ||||||||
| AT | 87 | Assessment Tools | Questions Logic | Reference Data Mgt | Ensure all relevant codesets (e.g., diagnosis codes) are continuously updated and available to end users and system administrators. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 88 | Assessment Tools | Questions Logic | Assessment functionality | Enable, maintain, and allow updates to logic that enables highlighting of incomplete and partially complete questions and modules. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 89 | Assessment Tools | Questions Logic | Assessment functionality | Enable, maintain, and allow pop up reminders to confirm that answers are valid and provide education on what a question means. | |||||||||||||||
| AT | 90 | Assessment Tools | Questions Logic | Assessment functionality | Allow questions/answers to collapse and expand questions manually according to user choice and automatically to facilitate ease of navigation. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 91 | Assessment Tools | System Logic | Assessment functionality | Implement, maintain, and update automated System Logic developed by EOHHS clinical and programmatic staff. The e-CAS runs System Logic to systematically and automatically calculate certain results based on UCA assessment responses. The objective of the System Logic is to calculate the following outputs based on Assessment Tool responses. System Logic will be based on specific responses to questions that if answered in a particular way will determine the desired output. System Logic may consider one response or a series of separate or conditional responses in order. All questions necessary for System Logic to run will be required Assessment Tool questions. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 92 | Assessment Tools | System Logic | Assessment functionality | Enable EOHHS users to define new System Logic and change some or all parts of existing System Logic over time. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 93 | Assessment Tools | System Logic | Assessment functionality | Calculate System Logic in real-time or near real time once an assessment is completed and approved. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 94 | Assessment Tools | System Logic | Assessment functionality | Only calculate System Logic for completed assessments. Do not calculate for “Cancelled” assessments. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 95 | Assessment Tools | System Logic | Assessment functionality | Facilitate “preliminary” and “final” System Logic results. System Logic results are considered “preliminary” until they are reviewed by appropriate staff (e.g., may be EOHHS, Independent Assessor, or LTSS TPA Prior Authorization staff) and signed off on. At this point, the System Logic results are only visible to these users. Once appropriate staff reviews and signs off on System Logic results, they are considered “finalized” and are available to other e-CAS users. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 96 | Assessment Tools | System Logic | Assessment functionality | Communicate final results of System Logic in a report that is appended to the Member’s record in the e-CAS and associated with the assessment for which the System Logic were run. | |||||||||||||||
| The report should include a summary that lists the final output of the System Logic (e.g., what the Member's CANS scores are, what LTSS programs a Member qualifies for, what their level of care would be, what their Rating Category is, etc.). The report should also contain a more detailed description of each System Logic and the Member’s results for each criterion (either meets/does not meet) related to program eligibility, level of care or rating category. For criteria that are met, the assessment information (i.e. score or other information) that triggered the criteria will be included. | X | 0 | 0 | 0 | 0 | 0 | ||||||||||||||
| AT | 97 | Assessment Tools | System Logic | Assessment functionality | Enable System Logic Outputs to be downloaded by users as well as viewable on the e-CAS web portal. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 98 | Assessment Tools | Manual Decision-Making | Assessment functionality | Facilitate recording of manual decisions made by users for programs that require manual decision-making to determine service/program qualification and affiliation of those decisions to a specific assessment. (For example, service qualification for the Home and Community Based (HCBS) Waiver programs is determined by Commonwealth Medicine (CWM) and Massachusetts Rehabilitation Commission (MRC) staff using UCA assessments. System Logic may be used to inform the clinical eligibility process but are not the only factor considered, so manual decision entry is required). Note: it may be that an assessment could require both automated decisions with System Logic and manual decision-making for certain services/programs. | X | 0 | 0 | 0 | 0 | 0 | |||||||||
| AT | 99 | Assessment Tools | Manual Decision-Making | Assessment functionality | Allow certain users to record manual decisions for service/program qualification. Users should be able to record information including but not limited to the following: |
• Service(s) for which a Member qualifies
• How much of the service for which a Member qualifies (e.g., number of days/hours/minutes)
• Rationale for service(s) qualification
| • Other notes/comments | X | 0 | 0 | 0 | 0 | 0 | ||||||||||||
| AT | 100 | Assessment Tools | Manual Decision-Making | Assessment functionality | Allow users to attach any required documentation (such as official decision notice) to the assessment. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AT | 101 | Time-to-Task Tool (TTT) | Versions | Assessment functionality | Allow different versions of the TTT, including Initial, Annual Re-Evaluation, Adjustment, Extension versions and differences based on Member characteristics(e.g. adult vs. pediatric). | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AT | 102 | Time-to-Task Tool (TTT) | Versions/Split TTT | Assessment functionality | Allow Members to have more than one active TTT assessment or “Split TTT” assessment to accommodate different schedules in different settings. For example, children and youth may have two active TTTs: one for school-time and one for vacation/summertime. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AT | 103 | Time-to-Task Tool (TTT) | Versions/Initial | Assessment functionality | Allow TTT Initial requests to allow for an assessment by an occupational therapist (OT) to provide their functional assessment in addition to the clinical assessment done by the nurse. Note: the OT and nurse should both have line of sight to each other’s assessments. Specifically, the nurse should be able to see the OT assessment, and vice versa. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AT | 104 | Time-to-Task Tool (TTT) | Versions/Initial | Assessment functionality | For TTT Initial requests, allow the OT to select the level of assist for each ADL, and make this information available for the nurse when they complete the TTT. The nurse should be able to override the OT’s level of assistance and also input the appropriate time and comments. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AT | 105 | Time-to-Task Tool (TTT) | Versions/Extension | Assessment functionality | Allow a modification of a TTT that accommodates Extension of a TTT for an additional period of time at the same level of service. For Extension of a TTT, allow certain users to create an extension TTT for up to a certain period of time that is configurable. After that time, additional Extension TTT would require special review by an EOHHS user before approval (for example, after a TTT is extended 90 days further extension would require EOHHS review and approval). Retroactive extensions also would require EOHHS review and approval. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AT | 106 | Time-to-Task Tool (TTT) | Outcome | Assessment functionality | Allow users to manually enter time in minutes, episodes per day and times per week and a justification/comment for each ADL/IADL task listed in the TTT. The number of minutes recommended is based on the clinical judgment of the user and accounts for a number of factors (e.g., Member self-sufficiency, informal supports, home environment). Note: For some ADLs, some Members may have differences within an ADL where there need to be additional/variable schedules within a day or week. For example, hands on assistance for medication administration may vary based on the cadence for the specific medication on any given day or Members may need more minutes eating dinner than breakfast. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AT | 107 | Time-to-Task Tool (TTT) | Outcome | Assessment functionality | Once the user has answered all questions but prior to assessment approval/completion, automatically calculate the TTT System Logic Output, including Day/Evening hours per week and Night hours per week rounded according to certain rules. For calculating TTT Outputs, allow different rounding rules for day/evening or night hours (for example, for Night hours rounding rules any amount up to 2 hours would automatically result in 2 hours of night time). | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AT | 108 | Time-to-Task Tool (TTT) | Outcome | Assessment functionality | Allow users to view the TTT Output prior to approving/completing the TTT form. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AT | 109 | Time-to-Task Tool (TTT) | Outcome | Assessment functionality | TTT Output should be provided with subtotals and totals for different elements of the tool, including for each task under the ADL or IADL; the total of all tasks for each ADL or IADL; the grand total of all ADL/IADLs, with differentiation between Day/Evening and Night hours for the whole TTT. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AT | 110 | Time-to-Task Tool (TTT) | Outcome | Assessment functionality | Communicate TTT Output in a report appended to the Member’s record in the e-CAS and associated with the TTT form for which the Output was calculated. The report should include a summary that lists the final outcome. The report should also contain a more detailed description of each ADL/IADL and the Member’s results for each item. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AT | 111 | Time-to-Task Tool (TTT) | Outcome | Assessment functionality | Display TTT Output for the TTT assessment. Note: for split PAs, the TTT should display both school and vacation hours in the summary/outcome. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AW | 112 | Assessment Status | Assessment Status Management | Assessment functionality | Manage assessment lifecycle, including: referral/request for assessment, creation of assessment, review of assessment, completion of assessment, expiration of assessment, and need for re-assessment. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AW | 113 | Assessment Status | Assessment Status Management | System LCM | Propose relevant/appropriate assessment statuses, develop with EOHHS staff, and gain approval. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AW | 114 | Assessment Status | Assessment Status Management | System LCM | Potential assessment statuses throughout the assessment lifecycle may include: |
• Referred for assessment
• In assessment queue
• Assigned to assessor
• In-process assessment
• Assessment cancelled
• In for review queue
• In review
• Review completed
• Assessment completed
• Assessment pending
• Assessment active
• Assessment inactive
| Please see RFR Section 1 for potential assessment status workflow. | X | 0 | 0 | 0 | 0 | 0 | ||||||||||||
| AW | 115 | Assessment Status | Assessment Status Management | Assessment functionality | Assign and track assessment status within the assessment lifecycle. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AW | 116 | Assessment Status | Assessment Status Management | System LCM | Add/delete assessment statuses as necessary if assessment workflows are modified. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AW | 117 | Assessment Status | Assessment Status Management | Assessment functionality | Facilitate both manual and automated workflows for different users depending on the assessment status. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AW | 118 | Assessment Status | Assessment Status Management | Assessment functionality | Enable changes in assessment status to be triggered automatically (for instance, a completed active assessment may expire after 12 months have elapsed; the assessment will change to inactive and the Member is referred back for re-assessment). | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AW | 119 | Assessment Status | Assessment Status Management | Assessment functionality | Enable changes in assessment status to be triggered by end user actions (for instance, a user may cancel an in-process assessment, making the assessment cancelled). | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AW | 120 | Assessment Status | Assessment Status Management | Assessment functionality | Enable different actions to be taken by different users depending on the assessment status. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AW | 121 | Assessment Status | Assessment Status Management | Assessment functionality | Send appropriate reminders to users depending on the assessment status. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AW | 122 | Assessment Status | Assessment Status Management | Assessment functionality | Display assessment status in assessment summaries available to users. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AW | 123 | Assessment Status | Assessment Status Management | Assessment functionality | Allow users to search for assessments based on assessment status (along with other search criteria). | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AW | 124 | Assessment Status | Assessment Status Management | Assessment functionality | Allow users with a workflow queue of assessments to filter and arrange assessments based on assessment status. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AW | 125 | Assessment Status | Assessment Status Management | Assessment functionality | Allow for the prevention of more than one assessment from being active at a time. Whenever a new assessment is approved/completed, mark the prior assessment as inactive. EOHHS anticipates that the UCA Tool will only have one active assessment at a time, while CANS and TTT assessments may have multiple active assessments. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AW | 126 | Assessment/Tool Creation | Data Entry | Assessment functionality | Have the capability for users to create and complete assessments and forms. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AW | 127 | Assessment/Tool Creation | Data Entry | Assessment functionality | Develop and maintain user-friendly, easy-to-navigate interface for completion of assessments and forms. | X | 0 | 0 | 0 | 0 | 0 | |||||||
| AW | 128 | Assessment/Tool Creation | Data Entry | Assessment functionality | Allow for different reasons for assessment tool/form creation, which will enable different business processes, including new intakes, periodic or ad hoc updates, and the Review/Appeals process. |
Examples of UCA assessment creation reasons include:
| • | New Intake: Used when the Member is first assessed by an organization | ||||||||||||||||
| • | Scheduled Update: Used when there is a regular re-assessment due; user can select Quarterly, Semi-Annual, Annual, Bi-Annual | ||||||||||||||||
| • | Status Change: Used when there is a significant change in Member's status requiring a re-assessment (will vary based on program enrollment and organizational rules) | ||||||||||||||||
| Examples of TTT creation reasons include: Initial, Annual Re-Evaluation, Adjustment. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||
| AW | 129 | Assessment/Tool Creation | Data Entry | Assessment functionality | Allow users to save an assessment at any point during the data entry process and return to it at a later time/date. Users should be able to start/stop working on assessments an indefinite number of times. | X | 0 | 0 | 0 | 0 | 0 | ||||||
| AW | 130 | Assessment/Tool Creation | Data Entry | Assessment functionality | Provide the option of "auto-saving" an assessment every time a user enters information at the discretion of the user or as a mandate/policy enforced at the system level. | X | 0 | 0 | 0 | 0 | 0 | ||||||
| AW | 131 | Assessment/Tool Creation | Data Entry | Assessment functionality | If a user attempts to close an assessment in process, prompt the user to save the assessment. Once an assessment is saved, the user can leave the assessment and return to pick up where they left off at any time. | X | 0 | 0 | 0 | 0 | 0 | ||||||
| AW | 132 | Assessment/Tool Creation | Data Entry – Offline | Assessment functionality | All tools and forms that are a part of the e-CAS should have offline capabilities, meaning users should be able to access the forms, complete them while not online, and have tools/forms automatically synchronized once the user resumes online access to the e-CAS. | X | 0 | 0 | 0 | 0 | 0 | ||||||
| AW | 133 | Assessment/Tool Creation | Data Entry – Offline | Assessment functionality | Provide the ability for an assessment to be performed offline and to synchronize assessments completed offline with the hosted assessment tool upon reconnection. In some cases, assessments will be conducted in homes where Internet access is not available. The application must also include: |
-The ability for users to work with a select, limited, secured data set necessary to conduct an assessment from a portable computer or mobile device that is not connected over the Internet to the hosted assessment tool. This is referred to as “working offline.”
-The ability to work offline must enable users to conduct a full assessment, with all edits, audit and logging controls, data validation rules, and results calculations.
| -Offline capability must automatically populate (i.e. upload to and synchronize) the assessment tool’s database with updated data or new assessments upon connection. | X | 0 | 0 | 0 | 0 | 0 | |||||||||||
| AW | 134 | Assessment/Tool Creation | Data Entry – Offline | Accessibility Management | Recommend to EOHHS and apply appropriate security protocols and permissions to ensure the security of UCA assessment data when data entry occurs offline. For example, this may include download passwords or document permissions and passwords. | X | 0 | 0 | 0 | 0 | 0 | ||||||
| AW | 135 | Assessment/Tool Creation | Data Entry – Offline | Assessment functionality | In the case where the user’s offline tool is an old version of the assessment, questions/answers that have been completed offline will have been mapped to the new assessment format. The following actions are performed: | ||||||||||||
| · | Questions that have been mapped from an old to a new version are converted to the new version. | ||||||||||||||||
| · | Questions that are on the old version but not the new version are marked as “inactive” and cannot be updated. | ||||||||||||||||
| Questions that are new to the new version will obviously not be filled in and will remain unanswered. The assessor must answer these either online or download another offline PDF that is the new version and answer the questions. | X | 0 | 0 | 0 | 0 | 0 |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .