Copy of Soldiers Homes EMR RFR_Attachment A_RFR Functional Requirements.xlsx
XLSX spreadsheet 197 KB Posted
- Solicitation number
- BD-20-1039-EHS01-EHS01-49184
- Issued by
- Suffolk County, Massachusetts
About this file
This document is a Request for Response (RFR) issued by the Executive Office of Health and Human Services (EOHHS) on behalf of the Department of Veterans Services for the procurement of a comprehensive electronic medical records (EMR) system for the Soldiers' Home in Chelsea and the Soldiers' Home in Holyoke. The envisioned EMR system will fully replace the existing electronic records systems and paper-based medical records at the Soldiers' Homes. The RFR outlines detailed functional requirements across various modules including global features, care management, billing, fiscal and inventory management, and other business needs. Bidders must respond to all requirements and their responses will become part of the final awarded contract. No specific quantities or contract term are stated.
The RFR does not provide details on pricing terms, set asides, incumbents, or funding sources. However, it does outline that the system must support various billing and reimbursement methodologies including fee-for-service, per diem, fixed rates, self-pay, and sliding fee schedules. The system must also integrate across financial and service delivery reporting.
View the file
Other files
Show all 22
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
Table of Contents
| Soldiers’ Home Electronic Medical Record (EMR) |
| Request for Response |
| Table of Contents |
| Functional Requirements Sections |
| A. Global Features |
| A1 Electronic Medical Record (EMR) |
| A2 User Experience |
| A3 Communication/Letters |
| A4 Scheduling |
| A5 Workflows |
| A6 Verifications |
| A7 Forms |
| A8 Tasks |
| A9 Notifications |
| A10 Documentation Management |
| A11 Reporting |
| A12 Advanced Features |
| B. Care Management (Direct Provider Care – Inpatient, Outpatient, etc.) |
| B1 Pre-admission/Pre-Screening |
| B2 Census Management |
| B3 Regulatory Assessments |
| B4 Electronic Status Board |
| B5 Transitions of Care, Shared Care & Discharge Documents |
| B6 Referral Out Tracking |
| B7 Order Entry/Results documentation |
| B8 Medication Management |
| B9 Clinical Records Documentation |
| B10 Clinical decision support systems (CDSS) |
| B11 Point of Care |
| B12 SUD and MAT treatment (covered under 42CFR) |
| C. Billing |
| C1 Medicare/Private Payors Billing |
| C2 VA Billing |
| C3 Daily Charge Billing and other Charges (Self-pay) |
| C4 Budgeting, Analysis, Modeling and Forecasting – Interface from MMARS |
| C5 Resident Trust |
| D. Fiscal and Inventory Management |
| D1 Revenue Management |
| D2 Purchase Orders and Supply Management |
| E. Other Business Requirements |
| E1 Patient and Resident Portal |
| E2 Dorm/Domiciliary |
| E3 Quality Control and Incident Management |
| E4 Human Resources |
| E5 Certification/Licenses Management |
| E7 Resident Application Appeals/Reconsideration Tracking Process |
| F. Ancillary Services |
| F1 Connectivity to the community partners and specialty service providers |
| F1 Specialty modules for in-house providers |
IntroKey
| Soldiers’ Home Electronic Medical Record (EMR) | |
| Request for Response | |
| Introduction/Key | |
| Bidders must respond to all requirements in each of the tabs in the workbook. Responses will become part of the final awarded contract. Most of the responses in sections A-F will require an X in the appropriate Bidder Response column that indicates the Bidder’s proposed system’s ability to meet a specific requirement, followed by an explanation if needed of how the system meets the requirement. | |
| Bidder Response | Bidder Response Definition |
| Existing | The bidder’s solution meets the functional requirement "out of the box" as an existing component of its standard product, which is in operation at a minimum of one client site. The function exists without any modification to the front end coding or database structure and is set primarily through table building and parameter settings within the applications. This response indicates that no customization is required to meet the requirement. |
| Configuration | The bidder’s solution does not meet the functional requirement "out of the box," but the system will meet the functional requirement with existing configuration tools, modifiable templates, or similar methods and no programmatic changes are necessary to underlying front end coding or database structure. A highly trained system administrator is capable of making these kinds of changes to the system. |
| Customization | The bidder’s solution does not meet the functional requirement without modification to the existing code base and/or database structure. The bidder is warranting that it will meet this functional requirement by customizing the software. A developer from the bidder is required to make these kinds of modifications. Indicate in the comments if this customization is included in the base system cost or is detailed separately in the cost worksheet, including the Ref # in the cost worksheet |
| Planned | The bidder’s solution does not presently meet the functional requirement, but an upgrade to the proposed product is planned and will meet this requirement within the next 12 months. This response indicates that no configuration or customization will be required to meet the requirement and that the upgrade will be included as part of standard support. |
| Not Available | The bidder's solution will not address this functional requirement. There are no plans to add the functionality. |
| Bidder Comment | Additional Comments/Narrative are helpful in clarifying responses. Please enter explanatory text into the Comment section for any particular requirement that would benefit from additional information. Some requirements include a statement that begins with "Describe" - Bidders must insert the description in the comments line for that requirement. |
| Important Reminder - Enter the company name and date submitted at the top of each page & follow the following spreadsheet naming convention: (Bidder Name) Requirements Response (Date Submitted) | |
| Priority: | 1- Must Have, 2- Nice to Have |
Section A - Global Features
| Bidder Name: | Soldiers’ Home Electronic Medical Record (EMR) | ||||||||
| Submission Date: | Request for Response | ||||||||
| Section A - Global Features | |||||||||
| Requirement # | Priority | Requirement Description | Bidder Response | Bidder Comment/Description | |||||
| Section A - Global Features | Existing | Configuration | Customization | Planned | Not available | ||||
| A1 | Electronic Medical Record (Please refer to Care Management Requirements for more detail) | ||||||||
| A1.1 | 1 | The system shall maintain an integrated Electronic Medical Record (EMR) for every client to track all pertinent health data across all service modules (e.g. LTC, dorm, outpatient clinic, etc.). | |||||||
| A1.2 | 1 | The system shall permit a single client record to be used across all service modules. | |||||||
| A1.3 | 1 | The system shall have the ability to generate a unique client ID number. | |||||||
| A1.4 | 1 | The system shall provide availability of all client registration data as needed without the need for duplication of entry. | |||||||
| A1.5 | 1 | The system shall support flexible search criteria during the patient identification process. | |||||||
| A1.6 | 1 | The system shall have the ability to identify potential duplicates, and alerts the user of a potential duplicate during assignment of a new medical record number. | |||||||
| A1.7 | 1 | The system shall provide the capability to merge documentation into the correct medical record, such as: | |||||||
| a | Clinical documentation – assessments, progress notes, consult notes, care plans, etc. | ||||||||
| b | Orders | ||||||||
| c | Lab results | ||||||||
| d | Demographic information and VA documentation. The system shall have the ability to track applications for VA benefits as they are submitted for VA & Medical Billing purposes. | ||||||||
| e | Financial information including Vets' income accounts. | ||||||||
| A1.8 | 1 | The system shall provide the capability to un-merge records that have been incorrectly linked. Describe how the system addresses this requirement. | |||||||
| A1.9 | 1 | The system shall support setting up client registries to track clients based on grouping by diagnosis codes, problem, insurance coverage, etc. Describe how the system manages client registries. | |||||||
| A1.10 | 1 | The system shall support hardware compatibility - ability to view/access/edit data across all deployed devices (laptop, tablet, phone). | |||||||
| A2 | User Experience | ||||||||
| A2.1 | 1 | The system shall have graphic user interface (GUI) that is designed to be configurable based on the needs of the specific user. Please describe your default GUI capabilities and their configurability for following user groups: administration, clinical staff, fiscal staff, billing staff, dorm staff, ancillary services staff, patient & family etc. | |||||||
| A2.2 | 1 | The screens shall be intuitive, streamlined, flexible and easily customized across all modules and settings. | |||||||
| A2.3 | 1 | The system shall bridge communication gaps by providing the care team with tools such as secure voice communication, text messaging, and smart alerting on a single smartphone device. | |||||||
| A2.4 | 1 | The system shall have dashboard feature that is designed to be configurable based on the needs of the specific user. Please describe your default dashboard capabilities and their configurability for following user groups: administration, clinical staff, fiscal staff, billing staff, dorm staff, ancillary services staff, etc. | |||||||
| A2.5 | 1 | The system shall flag incomplete or invalid data entry in an obvious manner to the user so that needed corrections are clear. | |||||||
| A3 | Communications/Letters | ||||||||
| A3.1 | 1 | The system shall allow for set up of letter templates with configurable content. | |||||||
| A3.2 | 1 | The system shall allow users to define standard letters and notices using data from the system to populate key fields. | |||||||
| A3.3 | 1 | The system shall allow for free text to be included in standard letters. | |||||||
| A3.4 | 1 | The system shall have the ability to add State and SH logo to letters. | |||||||
| A3.5 | 1 | The system shall have the ability to add agency/site specific letterhead to letters. | |||||||
| A3.6 | 1 | The system shall maintain dates of correspondence to allow for tracking of communication. | |||||||
| A3.7 | 1 | The system shall have the ability to maintain a record of all communications with the ability to recreate the correspondence including content. | |||||||
| A3.8 | 1 | The system shall have the ability to date and timestamp letters. | |||||||
| A3.9 | 1 | The system shall create and store a pdf of each letter. | |||||||
| A3.10 | 1 | The system shall support sending electronic and/or hard copy communications to clients, guardians, outside providers, internal staff, other agencies, etc. | |||||||
| A4 | Scheduling (Please refer to Care Management Requirements for more detail) | ||||||||
| A4.1 | 1 | The system shall provide a customizable scheduling feature to schedule patient internal and external appointments and events. | |||||||
| A4.2 | 1 | The system shall provide a customizable scheduling feature to schedule staff time and track staff utilization. | |||||||
| A5 | Workflows | ||||||||
| A5.1 | 1 | The system shall support setting up automated business workflows. For instance, certain orders should have an approval step and then become treatment actions. In other cases, an assessment is triggered that becomes another team members activity to complete. | |||||||
| A5.2 | 1 | The system shall present user with workflows that are user specific (administration, nursing, nutrition, social work, dorm, etc.) | |||||||
| A5.3 | 1 | The system shall prompt user through the work process based on the specific function being performed. | |||||||
| A5.4 | 1 | The system shall have a checklist or task bar to indicate progress towards completion of started process. For example, new admission process that prompts the user through the admission process and tracks completion of required areas. | |||||||
| A6 | Verifications | ||||||||
| A6.1 | 1 | The system shall have an e-signature function to endorse orders, consult forms, reports, assessments, approve data changes and/or collect consents. | |||||||
| A6.2 | 1 | The system shall have an e-Prescription function. This function should meet standards for transmittal of CII controlled substances. | |||||||
| A7.1 | Forms | ||||||||
| A7.1 | 2 | The system shall have the ability to allow for development of custom forms. The forms shall allow for the creation of new fields. Forms can support various objects such as textboxes, radio buttons, DDLBs, and combo-boxes, etc. with the possibility of being populated with user-defined data. This includes the ability to map to all VA forms. As an example VA 1010SH. See Appendix G. | |||||||
| A8 | Tasks | ||||||||
| A8.1 | 1 | The Business shall have the ability to oversee and manage tasks and their deadlines. In order to be compliant with legislation and policy, as well as best practices, deadlines need to be set for a variety of tasks. | |||||||
| A8.2 | 1 | The system shall be designed so that the users see their tasks when they log into the system. Any tasks that are overdue or approaching their due date will be listed first. Task list can be sorted by any data element. | |||||||
| A8.3 | 1 | The system shall be designed so that when a deadline is set for a task, the system will take an action based on the deadline approaching, or passing. Actions can include sending a reminder task to the nursing team member or escalating visibility of the task to the Nurse Supervisor. | |||||||
| A9 | Notifications | ||||||||
| A9.1 | 1 | The system shall allow Business the ability to oversee and manage system notifications. The means of receiving notifications should be variable, by user preference (e.g., phone, email, PCS, pager, fax, remote printer, etc.). | |||||||
| A9.2 | 1 | The system shall allow users to create a notification to one or many users. | |||||||
| A9.3 | 1 | The system shall allow Business the ability to configure system notifications depending on certain criteria. | |||||||
| A9.4 | 1 | The system shall allow Business the ability to modify the number and frequency of system notifications. | |||||||
| A9.5 | 1 | The system shall allow notifications to be automatically generated from the scheduler in real-time as events occur or according to configurable timeframes. | |||||||
| A10 | Document Management | ||||||||
| A10.1 | 1 | The system shall provide functionality for capturing, storing and retrieving documents in electronic format. Please describe your Electronic Document Management functionality. |
| A10.2 | 1 | The system shall provide the ability to scan or upload documents of different file types (e.g., PDF, Word, Excel) and link them to different areas of the client's record. |
| A10.3 | 1 | The system shall support a scanning process that allows user to index the scanned document for organization and easier retrieval. |
| A10.4 | 1 | The system shall support the use of checklists to facilitate and organize the scanning process. |
| A10.5 | 1 | The system shall support the recording of documentation that is transmitted to other organizations. |
| A10.6 | 1 | The system shall have the ability to maintain a historical record of all records transmitted. |
| A11 | Reporting | |
| A11.1 | 1 | The system shall generate any number of custom reports that can be placed on menus in a user-defined location. The system shall have the capability of reporting on any group of data field in the entire system including user-defined location; can perform multi-layered sort and select; has the ability to utilize wild cards in any data position of a field to select item; has the ability to compute on any field or groups of fields. The system shall send the outputting reports on a manual or automated basis to the screen, printer, standard ASCII file format, and PC application formats (XLS, WK*, MDB, DIF, etc.) Describe how will the system decipher internal reports versus external reports generated on a different system example virtual gateway with DPH? |
| A11.2 | 1 | The system shall support standard reports that can be run on demand for key reporting data. |
| A11.3 | 1 | The system shall support ad hoc reports that are parameter driven to allow end users to easily create custom reports based on the parameters in the report design such as Pinnacle Report or Resident's Birthday Report. |
| A11.4 | 1 | The system shall allow end users to easily create a host of custom views of the data. |
| A11.5 | 1 | The system shall provide the ability for Dashboard reports to be created by user or group of users so that the system will produce and update reports that monitor key elements from the data warehouse. |
| A11.6 | 1 | The system shall support the ability to extract data views for export into other applications for presentation and analysis. |
| A11.7 | 1 | The system shall provide the ability to report historical trends for outcome reporting. |
| A11.8 | 1 | The system shall support reporting of Medicare QM Measures. The short stay resident quality measures show the average quality of resident care in a nursing home for those who stayed in a nursing home for 100 days or less or are covered under the Medicare Part A Skilled Nursing Facility (SNF) benefit. Short-stay residents often are those recovering from surgery or being discharged from a hospital stay. |
The long stay resident quality measures show the average quality of care for certain care areas in a nursing home for those who stayed in a nursing home for 101 days or more.
| A11.9 | 1 | The system shall display and report the client’s status relative to clinical, financial, VA eligibility criteria. | |
| A11.10 | 1 | The system shall allow for the user to have control over determining what records can be selected for historical or longitudinal storage. | |
| A12 | Advanced Features | ||
| A12.1 | 2 | The system shall utilize advanced workflow technologies such as Natural Language Processing (NLP) and artificial intelligence (AI). | |
| A12.2 | 2 | The required GUI should have a draw/paint input feature. This tool could be used, for example, to identify the area of the body affected by drawing on a given picture of a human body. | |
| A12.3 | 1 | The system shall provide (or work in conjunction with) an appropriate speech recognition system such as Dragon. Speech recognition may be used to dictate narratives directly into the system. The primary user group will be physicians entering progress notes and consult notes. The system should utilize a large active vocabulary which contains words and terms including medication names, medical procedures, diagnoses, symptoms and conditions, and common acronyms that most doctors use on a regular basis. Ideally, the set of vocabulary can be tailored to include new words, specialized terms, and proper names. | |
| A12.4 | 1 | The system shall have an integrated bed management feature. It should track all attributes of a room such as location (e.g., room number, current patient, wing, floor, SNF designation) whether the room is for male or female patients, and whether or not the room has facilities such as oxygen, suction, etc. | |
| A12.5 | 1 | The system shall include a Bar Code Inventory system for the following areas: | |
| a | Patient bracelet (to track patient location) | ||
| b | Pharmacy (for medication/supplies inventory) | ||
| c | Stores/CSR (for inventory of supplies, food, etc.) | ||
| d | Property (for inventory of hospital assets) or have the capability to work with the existing WASP system. | ||
| A12.6 | 2 | The system shall provide a character recognition feature (OCR) to allow the extraction of text from scanned documents. | |
| A12.7 | 1 | The system shall provide users with clinical analytics and population health tools. | |
| A12.8 | 1 | The system shall provide Telemedicine functionality. | |
| A12.9 | 2 | The system shall have a report designer to design how reports will look and support a number of reports including columnar, cross-tab, mailing labels, form letters, graph, etc. |
Section B - Care Management
| Bidder Name: | Soldiers’ Home Electronic Medical Record (EMR) | ||||||||
| Submission Date: | Request for Response | ||||||||
| Section B - Care Management | |||||||||
| Requirement # | Priority | Requirement Description | Bidder Response | Bidder Comment/Description | |||||
| Section B - Care Management | Existing | Configuration | Customization | Planned | Not available | ||||
| B1 | Pre-Admission/Admission | ||||||||
| Demographic & Military Documentation | |||||||||
| B1.1 | 1 | The system shall capture client's demographic information submitted during pre-admission/admission process. For minimum required data fields please refer to current SH Application Documentation in Appendix C. | |||||||
| B1.2 | 1 | The system shall capture next of kin and guardian information. The system shall capture and track the history of information related to other significant people for each client. | |||||||
| B1.3 | 1 | The system shall capture State & Federal Military Service record requirements, including DD214 (military documents) and generate Military Information Report. This includes Service Connected Disability rating. For minimum required data fields please refer to the Military Information Report example in Appendix D. | |||||||
| B1.4 | 1 | The system shall have data fields to capture incoming diagnosis and admission ICD10 code. | |||||||
| B1.5 | 1 | The system shall capture contact information for outside professionals involved in client's care (i.e. attending physician, alternate physician, referring physician, etc.). | |||||||
| B1.6 | 1 | The system shall allow for user to upload "attachments" to the client record when needed to provide additional documentation, such as: proof of residency, proof of income, medical history, military documentation etc. | |||||||
| B1.7 | 1 | The system shall store and retrieve client information submitted on referral/ application date and allow screening for clients not admitted for services or placed on waitlist. | |||||||
| B1.8 | 1 | The system shall provide user with the capability to upload client's picture to their admission/medical record. | |||||||
| B1.9 | 1 | The system shall generate a printable Face Sheet that provides summary of client's demographic and clinical information. | |||||||
| B1.10 | 1 | The system shall capture Alcohol/drug test results. | |||||||
| B1.11 | 1 | The system shall capture client's CORI results. | |||||||
| B1.12 | 1 | The system shall generate client's ID card, bracelet and labels with demographic, code status, military, insurance and next of kin information. | |||||||
| B1.13 | 1 | The system shall have the ability to capture and report on data, such as: application submitted date, application review date, application status. | |||||||
| B1.14 | 1 | The system shall manage beds availability and allocation. | |||||||
| B1.15 | 1 | The system shall allow for additional data elements and screens to be added to the pre-admission/admission/process. | |||||||
| B1.16 | 1 | The system shall have the ability to add clinical data/make changes as part of the pre-admission process to determine clinical eligibility prior to a full assessment. Describe your approach to adding additional/changing data, such as a clinical screening tool, to the system. | |||||||
| B1.17 | 1 | The system shall permit a client be entered retroactively in the system. | |||||||
| Insurance | |||||||||
| B1.18 | 1 | The system shall capture financial information to determine who is responsible to pay for some or all of the services provided. | |||||||
| B1.19 | 1 | The system shall allow for multiple fund sources to be identified per client. For example, Medicaid, Medicare, VA, Private Insurance, Self-pay, etc. | |||||||
| B1.20 | 1 | The system shall capture insurance information (Medicare #, Medicaid #, private insurance #). | |||||||
| B1.21 | 1 | The system shall allow for an insurance eligibility transaction to be sent to each payer identified to confirm the financial information. This can be a real time 270/271 with a response that can be viewed and then accepted by the user. Describe the level of integration of standard HIPAA eligibility transactions in the system. | |||||||
| B1.22 | 1 | The system shall incorporate the results of the eligibility checking in each client’s record. | |||||||
| B1.23 | 1 | The system's insurance eligibility information shall include at a minimum: funding source or payer, aid category or plan information, member ID, group number, eligibility start date, eligibility end date (if ended), and subscriber name and date of birth if different than client. | |||||||
| Waitlist Management | |||||||||
| B1.24 | 1 | The system shall provide capability to manage admission waitlist. | |||||||
| B1.25 | 1 | The system shall have the ability to have separate waiting lists for all available services such as LTC, Dorm, Outpatient clinic, Post-acute care, etc. This shall include an active and inactive list. | |||||||
| B1.26 | 1 | The system shall have the ability for the waiting list to be sorted by user-defined criteria. | |||||||
| B1.27 | 1 | The system shall identify clients with priority needs that can prompt the admission committee by moving them up in the wait list queue. The default is first come, first served. | |||||||
| B1.28 | 1 | The system shall determine the number of individuals awaiting admission at any point in time and the specific services for which they are waiting for, and also identify trends over time. | |||||||
| B1.29 | 1 | The system shall provide the ability to see wait time per client/patient. | |||||||
| B1.30 | 1 | The system shall provide for automatic updates to the waiting list when clients are admitted. | |||||||
| B1.31 | 1 | The system shall compute the average wait time per service category (LTC, Post-Acute Care, Dorm, Adult Day Care etc.) and user defined demographic. | |||||||
| B1.32 | 1 | The system shall compute by service category the system’s service utilization rates, i.e., occupancy/actual enrollment against capacity. | |||||||
| B1.33 | 1 | The system shall compute the average wait time between submission of application and admission. | |||||||
| B1.34 | 1 | The system shall generate a variety of user-defined reports that can be used by the Business to monitor utilization. | |||||||
| B1.35 | 1 | The system shall allow for an automated letter process to invite applicant to pre-admission meeting. | |||||||
| B1.36 | 1 | The system shall allow for an automated letter process to notify client when admission decision is made. | |||||||
| Releases, Consents and Disclosures | |||||||||
| B1.37 | 1 | The minimum content of documents as required by federal regulation for LTC facilities and fundamental practice standards is outlined in AHIMA's Long-Term Care Health Information Practice and Documentation Guidelines. Please refer to Appendix H. | |||||||
| B1.38 | 1 | The system shall provide a solution for capturing consents and electronic signatures that is in accordance with federal and state guidelines. Describe how the system captures e-signatures from clients. | |||||||
| B1.39 | 1 | The system shall record that the appropriate consent forms are e-signed and on file. | |||||||
| B1.40 | 1 | The system shall capture an Informed Consent for Use of a Restraint. | |||||||
| B1.41 | 1 | The system shall capture a Consent, Notice and Authorization to Use/Release Clinical Records. | |||||||
| B1.42 | 1 | The system shall capture a Notice of Bed Hold Policy and Readmission. | |||||||
| B1.43 | 1 | The system shall capture a Notice of Legal Rights and Services. | |||||||
| B1.44 | 1 | The system shall capture a Notice Before Transfer. | |||||||
| B1.45 | 1 | The system shall capture a Notice Prior to Change of Room or Roommate. | |||||||
| B1.46 | 1 | The system shall capture a Psychotropic Consent form for those on applicable medications. | |||||||
| B1.47 | 1 | The system shall capture an Advance Directives/Medical Orders for Life-Sustaining Treatment form (MOLST). [The MOLST form is a standardized medical order form that contains valid medical orders. These orders are the same as any other medical orders that are followed by health professionals.] | |||||||
| B1.48 | 1 | The system shall provide the ability to limit access to tracking and approving releases/consents/disclosures to specified staff. | |||||||
| B1.49 | 1 | The system provides the ability to define what constitutes the legal medical record. | |||||||
| B1.50 | 1 | The system shall provide the ability to print, such as: | |||||||
| a | Entire legal medical record as defined | ||||||||
| b | Select sections of the chart to print | ||||||||
| c | Set parameters of what is to be printed | ||||||||
| d | Date range for notes | ||||||||
| B1.51 | 1 | The system shall provide the ability to print specified PHI as authorized according to minimum necessary rule. | |||||||
| B1.52 | 1 | The system shall provide the ability to exclude non-discoverable information from release. | |||||||
| B1.53 | 1 | The system shall provide the ability to create an electronic file for CCD (continuity of care document). | |||||||
| B1.54 | 1 | The system shall provide the ability to release record electronically. | |||||||
| B1.55 | 1 | The system shall provide the ability to send electronic record file via methods, such as: | |||||||
| a | Encrypted | ||||||||
| b | Patient portal |
[For detailed requirements, see Section E - Other Business Requirements]
| c | Parameter driven CD | |||
| d | Via Health Information Exchange (HIE) | |||
| B1.56 | 1 | The system shall provide the ability to track and support releases, such as: | ||
| a | Release of Information (ROI) | |||
| b | Individual requests | |||
| c | Court orders | |||
| B1.57 | 1 | The system shall have the ability to support multiple types and tiers of releases of information (ROI), such as: | ||
| a | Substance use | |||
| b | HIV | |||
| c | Peer protected information | |||
| B1.58 | 1 | The system shall provide the ability to check off what is to be released. | ||
| B1.59 | 1 | The system shall provide the ability to configure a checklist to assure compliance with releases. | ||
| B1.60 | 1 | The system shall provide the ability to track information concerning requests for releases of information, such as: | ||
| a | Who is requesting | |||
| b | Who is client/patient | |||
| c | What is being requested | |||
| d | Date of request | |||
| e | Validity of request | |||
| f | Who authorized release | |||
| g | What was released | |||
| h | Date of release | |||
| i | How released | |||
| B1.61 | 1 | The system shall have the ability to track and revoke consents. | ||
| B1.62 | 1 | The system shall have the ability to track that forms have been given to clients. | ||
| B1.63 | 1 | The system shall provide the ability to scan in signed releases, such as: | ||
| a | Court orders | |||
| b | Legal documents | |||
| c | Consents to treat | |||
| d | Consents to release data | |||
| B1.64 | 1 | The system shall provide the ability to track/note that the releases have been signed. | ||
| B1.65 | 1 | The system shall support HIPAA management of non- Treatment, Payment and Healthcare Operations (non-TPO) disclosures. | ||
| B1.66 | 1 | The system shall support automatic alerts of disclosure limitations and potential HIPAA violations. | ||
| B1.67 | 1 | The system shall allow users to log and track requests. | ||
| B1.68 | 1 | The system shall provide the ability to identify and verify consents. | ||
| B1.69 | 1 | The system shall provide the ability to identify and verify Legally Authorized Representatives (LARs). | ||
| B1.70 | 1 | The system shall provide the ability to have an audit trail for items, such as: | ||
| a | Printing all or parts of the medical record | |||
| b | Releases of information | |||
| c | Chart Completion | |||
| B1.71 | 1 | The system shall provide the ability to prepare a centralized hard copy and electronic copy of the clinical record. | ||
| B1.72 | 1 | The system shall provide the ability to determine who has had access to the record. | ||
| B1.73 | 1 | The system shall provide the ability to track authorization to disclose (and any related HIPAA confidentiality requirements). | ||
| B1.74 | 1 | The system shall have the ability to provide information for Performance Improvement (e.g., outcomes and client/patient satisfaction). | ||
| B1.75 | 1 | The system shall provide the ability to limit and restrict certain clinical documents to read-only access. | ||
| B1.76 | 1 | The system shall have the ability to identify duplicate numbers or clients with more than one number. | ||
| B1.77 | 1 | The system shall provide the ability to freeze record at a point in time to produce a “Snapshot”. A record needs to be secured in such a way as to prevent overwrites or changes at and from a particular point. Describe how this can be achieved. | ||
| B1.78 | 1 | The system shall provide the ability to limit the release of records. | ||
| VA Documentation | ||||
| B1.79 | 1 | The system shall capture the DD214 military discharge form information. The DD Form 214, Certificate of Release or Discharge from Active Duty, generally referred to as a "DD 214", is a document of the US DoD, issued upon a military service member's retirement, separation, or discharge from active duty in the Armed Forces of the United States. For specific data fields please refer to DD214 form in Appendix D. | ||
| B1.80 | 1 | The system shall capture information needed and support submission (scan/email/online) of the VA Form 1010 EZ. This is an application for VA benefits. For specific data fields please refer to 1010 EZ form in Appendix E. The 1010EZ is required for the LTC and Dorm services. | ||
| B1.81 | 1 | The system shall capture information needed and support submission (online) of the VA Form 1010 SH. This is a State Home Program Application For Veteran Care Medical Certification. For specific data fields please refer to 1010 SH form in Appendix F. The 1010SH is required is required for the LTC and Dorm services. | ||
| B2 | Census Management | |||
| B2.1 | 1 | The system shall allow tracking of client/patient throughout the facility across all services/programs. | ||
| B2.2 | 1 | The system shall be able to combine the daily nursing activities information with bed assignment and staffing information. | ||
| B2.3 | 1 | The system solution shall allow users to track Real-Time Census and Occupancy levels. | ||
| B2.4 | 1 | The system solution shall allow users to track Leave of Absence and Bed Hold Management. | ||
| B2.5 | 1 | The system shall have the ability to determine program length such as LTC, Domiciliary length of stay calculations. For VA specific census requirements please refer to VA billing form in Appendix G. | ||
| B2.6 | 1 | The system shall track multiple lengths of stay based on the services/programs such as LTC, Dorm that the client is registered or admitted into. | ||
| B2.7 | 1 | The system shall track length of stay of an entire Episode of Care that can span entry and transfer from one service/program or level of care to another. | ||
| B2.8 | 1 | The system shall have the ability to have a single longitudinal record for an individual over time. Describe the systems design approach to the maintenance of a longitudinal record. | ||
| B2.9 | 1 | The system shall allow for online facility wide view of census. In addition, the user shall be able to generate and print a daily census report for the LTC and dorm. | ||
| B2.10 | 1 | The system shall provide the ability to view the Census by specific groupings, such as: | ||
| a | Unit/"Home" | |||
| b | Building | |||
| c | Service/Program (LTC/Dorm) | |||
| B2.11 | 1 | The system shall provide a mechanism for handling events, such as: | ||
| a | Pre-admission | |||
| b | Admission | |||
| c | Triage | |||
| d | Discharge | |||
| e | Transfers such as: | |||
| i | Trigger notice to Housekeeping | |||
| ii | Trigger notice to Dietary | |||
| iii | Bed Hold/LOA (leaves of absence) | |||
| iv | Internal Transfer Process | |||
| f | Current status of client/patient in system | |||
| B3 | Regulatory Assessments | |||
| B3.1 | 1 | The system shall have the ability to add clinical data as part of the pre-admission process to determine clinical eligibility prior to a full assessment. Describe your approach to adding additional data, such as a clinical screening tools to the system. | ||
| B3.2 | 1 | The system has the ability to integrate with third party licensed assessment tools (as allowed with proprietary tools). | ||
| B3.3 | 1 | The system shall incorporate the implementation and use of standardized and/or other customer defined screening and assessment instruments. | ||
| B3.4 | 1 | The system shall support an interdisciplinary assessment process that uses the Resident Assessment Instrument (RAI) Minimum Data Set (MDS) and Care Area Assessments (CAA) as the base assessment tools. The minimum content as required by federal regulation for LTC facilities and fundamental practice standards is outlined in AHIMA's Long-Term Care Health Information Practice and Documentation Guidelines. Please refer to Appendix H. | ||
| B3.5 | 1 | The system shall support the Patient Driven Payment Model (PDPM) MDS assessment data collection. Effective beginning October 1, 2019, PDPM will be used under the Skilled Nursing Facility (SNF) Prospective Payment System (PPS) for classifying SNF patients in a covered Part A stay. | ||
| B3.6 | 1 | The system shall provide all CMS-required Minimum Data Sets (MDSs), and streamlines the data capture process |
by mapping clinical and administrative data to the MDS. The fully-compliant MDS Assessment shall be embedded into the care provider’s daily workflow via timely reminders that are delivered to desktops and status dashboards. To prevent incomplete documentation, MDS sections shall not be marked as completed if conflicts or unanswered questions remain.
| B3.7 | 1 | The system shall allow users to share query responses between the clinical assessment and the MDS. |
| B3.8 | 1 | The system shall allow users to recall values from either clinical assessments or previous MDSs. |
| B3.9 | 1 | The system shall allow users to automatically trigger the appropriate Care Assessment Areas (CAAs) based on MDS entries. |
| B3.10 | 1 | The system shall allow users to check for conflicts within each MDS section and the entire document. |
| B3.11 | 1 | The system shall allow users to seamlessly populate the client's record with the appropriate data from a finalized MDS. |
| B3.12 | 1 | The system shall manage MDS submissions (batch) and facilitate quality indicator reporting. |
| B3.13 | 1 | The system shall allow the MDS coordinator and approved nursing staff generate and edit the CMS 672 and 802 reports. Also, the next appropriate MDS shall be generated by the system upon admission, and as each MDS is completed. |
| B3.14 | 1 | The system shall support other assessments and collect information that supplements and/or supports the comprehensive assessment rather than readdress it. Please describe your approach to the assessment process and how your system minimizes physician and nursing burnout. The minimum content as required by federal regulation for LTC facilities and fundamental practice standards is outlined in AHIMA's Long-Term Care Health Information Practice and Documentation Guidelines. Please refer to Appendix H. |
| B3.15 | 1 | The system shall provide the user with the ability to use the Resident Assessment Instrument - In-Patient Rehabilitation Facility-Patient Assessment Instrument (IRF-PAI). The Inpatient Rehabilitation Facility Patient Assessment Instrument (IRF-PAI) is collected on all Medicare patients who receive services from an inpatient rehabilitation unit or hospital. The data collected for IRF-PAI are used to measure quality of care. |
| B3.16 | 1 | The system shall create and document a Hospice Item Set (HIS). The HIS is a standardized set of items intended to capture patient-level data on each hospice patient admission. |
| B3.17 | 1 | The system shall create and document a Nursing Preadmission Assessment. The minimum content as required by federal regulation for LTC facilities and fundamental practice standards is outlined in AHIMA's Long-Term Care Health Information Practice and Documentation Guidelines. Please refer to Appendix H. |
| B3.18 | 1 | The system shall create and document a Nursing Initial Admission Assessment. The minimum content as required by federal regulation for LTC facilities and fundamental practice standards is outlined in AHIMA's Long-Term Care Health Information Practice and Documentation Guidelines. Please refer to Appendix H. |
| B3.19 | 1 | The system shall create and document an Initial Care Plan. The minimum content as required by federal regulation for LTC facilities and fundamental practice standards is outlined in AHIMA's Long-Term Care Health Information Practice and Documentation Guidelines. Please refer to Appendix H. |
| B3.20 | 1 | The system shall create and document an Interdisciplinary Care Plan. The minimum content as required by federal regulation for LTC facilities and fundamental practice standards is outlined in AHIMA's Long-Term Care Health Information Practice and Documentation Guidelines. Please refer to Appendix H. |
| B3.21 | 1 | The system shall create and document a Fall Risk Assessment. The minimum content as required by federal regulation for LTC facilities and fundamental practice standards is outlined in AHIMA's Long-Term Care Health Information Practice and Documentation Guidelines. Please refer to Appendix H. |
| B3.22 | 1 | The system shall create and document a Skin Assessment. The minimum content as required by federal regulation for LTC facilities and fundamental practice standards is outlined in AHIMA's Long-Term Care Health Information Practice and Documentation Guidelines. Please refer to Appendix H. |
| B3.23 | 1 | The system shall create and document a Bowel and Bladder Assessment. The minimum content as required by federal regulation for LTC facilities and fundamental practice standards is outlined in AHIMA's Long-Term Care Health Information Practice and Documentation Guidelines. Please refer to Appendix H. |
| B3.24 | 1 | The system shall create and document a Pre-Restraining Assessment. The minimum content as required by federal regulation for LTC facilities and fundamental practice standards is outlined in AHIMA's Long-Term Care Health Information Practice and Documentation Guidelines. Please refer to Appendix H. |
| B3.25 | 1 | The system shall create and document a Self-Administration of Medication Assessment. The minimum content as required by federal regulation for LTC facilities and fundamental practice standards is outlined in AHIMA's Long-Term Care Health Information Practice and Documentation Guidelines. Please refer to Appendix H. |
| B3.26 | 1 | The system shall create and document a Physical Restraint Assessment. The minimum content as required by federal regulation for LTC facilities and fundamental practice standards is outlined in AHIMA's Long-Term Care Health Information Practice and Documentation Guidelines. Please refer to Appendix H. |
| B3.27 | 1 | The system shall create and document a Physical Restraint Elimination |
Assessment. The minimum content as required by federal regulation for LTC facilities and fundamental practice standards is outlined in AHIMA's Long-Term Care Health Information Practice and Documentation Guidelines. Please refer to Appendix H.
| B3.28 | 1 | The system shall create and document a Nutrition Assessment. The minimum content as required by federal regulation for LTC facilities and fundamental practice standards is outlined in AHIMA's Long-Term Care Health Information Practice and Documentation Guidelines. Please refer to Appendix H. |
| B3.29 | 1 | The system shall provide the user with ability to create and document an Activities/Recreation/Leisure Interest Assessment. The minimum content as required by federal regulation for LTC facilities and fundamental practice standards is outlined in AHIMA's Long-Term Care Health Information Practice and Documentation Guidelines. Please refer to Appendix H. |
| B3.30 | 1 | The system shall create and document a Mental and Psychosocial Functioning Assessment. The minimum content as required by federal regulation for LTC facilities and fundamental practice standards is outlined in AHIMA's Long-Term Care Health Information Practice and Documentation Guidelines. Please refer to Appendix H. |
| B3.31 | 1 | The system shall create and document a Restorative/Rehab Nursing Assessment. The minimum content as required by federal regulation for LTC facilities and fundamental practice standards is outlined in AHIMA's Long-Term Care Health Information Practice and Documentation Guidelines. Please refer to Appendix H. |
| B3.32 | 1 | The system shall create and document a Pain Assessment such as: Initial pain assessment, Ongoing pain assessment, Re-assessment of pain (re-assessment in admitted Veterans shall be captured using the Pain Flow Sheet and on the MDS, including with any change in health status). |
| B3.33 | 1 | The system shall create and document a Social Service Assessment. Each department completes their assigned section(s) of the Initial MDS form. |
| B3.34 | 1 | The system shall create and document an Occupational Therapy Assessment. Each department completes their assigned section(s) of the Initial MDS form. |
| B3.35 | 1 | The system shall create and document a Physical Therapy Assessment. Each department completes their assigned section(s) of the Initial MDS form. |
| B3.36 | 1 | The system shall create and document a Full Head to Toe Assessment such as: neuro, respiratory, cardiac, abdominal, genitourinary, extremities and posterior surfaces incl. full set of Vital Signs. |
| B3.37 | 1 | The system shall create and document a Norton Scale Assessment. For specific data fields please refer to assessment form in Appendix I. |
| B3.38 | 1 | The system shall create and document a Wandering Assessment. For specific data fields please refer to assessment form in Appendix J. |
| B3.39 | 1 | The system shall create and document an Oral Assessment. For specific data fields please refer to assessment form in Appendix K. |
| B3.40 | 1 | The EMR shall provide the user with ability to create and document the Smoking Safety Assessment. For specific data fields please refer to assessment form in Appendix L. |
| B3.41 | 1 | The system shall provide the user with ability to create and document the AIMS Assessment. For specific data fields please refer to assessment form in Appendix M. |
| B3.42 | 1 | The system shall create and document a Veteran Education Assessment. For specific data fields please refer to assessment form in Appendix N. |
| B3.43 | 1 | The system shall create and document a Behavior Report. For specific data fields please refer to assessment form in Appendix O. |
| B3.44 | 1 | The system shall generate a Public Health Report (e.g., Tuberculosis) Assessment. For specific data fields please refer to assessment form in Appendix P. |
| B3.45 | 1 | The system shall support the LTC Survey data collection. For details please refer to the Long Term Care Survey Process (LTCSP) Procedure Guide in Appendix Q. |
| B3.46 | 1 | The system shall ensure that all required regulatory and any supporting assessments meet CMS submission criteria and are error free. Please describe your approach to quality and regulatory compliance assurance. |
| B3.47 | 1 | The system shall provide comprehensive assessment tools for documenting complex patient care scenarios, predictive and real-time surveillance alerts to identify suspected or unsuspected conditions, and the flexibility to restore orders and care plans for effective transitions across various care settings. |
| B4 | Electronic Status Board | |
| B4.1 | 3 | The system shall provide configurable electronic status board functionality. The system shall have the ability to display an accurate snapshot of the current patient activity in their current setting or assigned unit or other location. |
| B4.2 | 3 | The system shall have the ability to use icons to assure HIPAA compliance. | ||
| B4.3 | 3 | The system shall have the ability to include items, such as: | ||
| a | Room # | |||
| b | Staff assigned | |||
| c | Other staff assigned – such as supervisor | |||
| d | Appointments/tasks for today | |||
| e | Medications | |||
| f | Abnormal lab results | |||
| B5 | Transitions of Care, Shared Care & Discharge Documents | |||
| Note: The minimum content of documents as required by federal regulation for LTC facilities and fundamental practice standards is outlined in AHIMA's Long-Term Care Health Information Practice and Documentation Guidelines. Please refer to Appendix H for more details. | ||||
| B5.1 | 1 | The system shall provide the user with the ability to capture Shareable Plan of Care (including Goals and Instructions). | ||
| B5.2 | 1 | The system shall have the ability to create a client/patient discharge summary/is such as: | ||
| a | Summary Report - Discharge | |||
| b | Summary Report - Transfer | |||
| c | Summary Report - Consults | |||
| B5.3 | 1 | The system shall provide the user with the ability to generate Diagnostic Imaging Report (DIR). | ||
| B5.4 | 1 | The system shall provide the user with the ability to generate Operative Notes. | ||
| B5.5 | 1 | The system shall provide the user with the ability to capture Procedure Notes. | ||
| B5.6 | 1 | The system shall provide the user with the ability to capture History and Physical Notes. | ||
| B5.7 | 1 | The system shall provide the user with the ability to capture Continuity of Care Document (CCD). | ||
| B5.8 | 1 | The system shall provide the user with the ability to generate Discharge/Physician/PCP Order. | ||
| B5.9 | 1 | The system shall provide the user with the ability to capture Discharge Note. | ||
| B5.10 | 1 | The system shall provide the user with the ability to capture Transfer Form. | ||
| B5.11 | 1 | The system shall provide the user with the ability to generate Physician’s Discharge Summary/ Discharge Record. | ||
| B5.12 | 1 | The system shall provide the user with the ability to generate a summary of the Patient Education Resources. | ||
| B5.13 | 1 | The system shall provide the user with the ability to generate Medication Reconciliation form (hospital d/c list vs. facility or physician list). | ||
| B5.14 | 1 | The system shall provide the user with the ability to capture Death Certificate Medical Certifier worksheet. | ||
| B5.15 | 1 | The system shall provide the user with the ability to generate Death Certificate Attestation. | ||
| B5.16 | 1 | The system shall provide the user with the ability to capture Mortician’s Certificate of Removal. | ||
| B5.17 | 1 | The system shall provide the user with the ability to generate RN Pronouncement. | ||
| B5.18 | 1 | The system shall provide a way to ensure that all admissions are discharged at the appropriate time. | ||
| B5.19 | 1 | The system shall associate a discharge with an admission. | ||
| B5.20 | 1 | The system shall only allow a discharge on an active admission. | ||
| B5.21 | 1 | The system has the ability to capture referrals for follow-up care/services. | ||
| B5.22 | 1 | The system shall record the referral information and allow for follow-up documentation to document the status and disposition of the referral. | ||
| B5.23 | 1 | The system shall capture the following for Transfers: | ||
| a | The program/site/area/region/facility an individual is transferred to/from | |||
| b | The effective date of transfer | |||
| c | The reason for transfer | |||
| d | The reason for discharge from a program (but staying open in another one) | |||
| B5.24 | 1 | The system shall have the ability to re-open a closed record when client/patient returns for services. | ||
| B5.25 | 1 | The system shall have the ability to view previous record information. | ||
| B5.26 | 1 | The system has the ability to copy/edit previous information into a new admission without losing historical record. | ||
| B5.27 | 2 | The system shall have the ability to set triggers at Transfer and Discharge to send alert to: | ||
| a | Housekeeping | |||
| b | Bed placement coordinator for facility/setting | |||
| c | Admission or administrative office maintaining current status (bed availability) | |||
| d | Scheduling to cancel future appointments | |||
| B5.29 | 1 | The system shall have the ability to create a workflow for a Pre-discharge checklist. | ||
| B5.30 | 1 | The system shall allow for the disenrollment of a client from the system indicating that this client is no longer the responsibility of the Soldiers' Home. | ||
| B5.31 | 1 | The system shall maintain a historical record of all admissions and discharges. | ||
| B5.32 | 1 | The system has the ability to track reason for disenrollment, such as: death, choice, ed, change in need/eligibility. | ||
| B5.33 | 1 | The system shall track the effective dates of disenrollment. | ||
| B5.34 | 1 | The system shall generate real time communications necessary at time of disenrollment and would allow for notification to client and providers who have been working with client. | ||
| B6 | Referral Out Tracking | |||
| B6.1 | 1 | The system shall have the ability to generate a referral form to link client/patients to ancillary treatment. | ||
| B6.2 | 1 | The system shall have the ability to electronically send referrals out. | ||
| B6.3 | 1 | The system shall have the ability to define standard reasons for referral for use on referral form. | ||
| B6.4 | 1 | The system shall have the ability to record multiple referrals per client/patient. | ||
| B6.5 | 1 | The system shall have the ability to capture data elements related to referring a client/patient to another provider, such as: | ||
| a | Agency | |||
| b | Program | |||
| c | Contact person | |||
| d | Client/patient name | |||
| e | Client/patient ID | |||
| f | DOB | |||
| g | Insurance | |||
| h | Diagnosis | |||
| i | STAT Orders | |||
| j | Recent treatment plan | |||
| k | Admit date | |||
| l | Referral date | |||
| m | User-defined reasons for referral | |||
| n | Transfer from | |||
| o | Transfer to | |||
| p | Aftercare (age related) arrangements notes | |||
| q | User-defined fields |
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 .