POST - Appendix 4 - MDH EHR OCMP-22-18251_Functional_and_Business_Requirements_twfr_1-13-2022_AMENDED_07.18.22 (Locked).xlsx
XLSX spreadsheet 70 KB Posted
- Solicitation number
- BPM030665
- Issued by
- Maryland
About this file
The document is an Appendix 4 - Functional and Business Requirements from a Request for Proposals (RFP) issued by the Maryland Department of Health (MDH) to procure a multi-tenant, subscription-based Software as a Service (SaaS) solution for Electronic Health Records (EHR) and revenue-cycle management for eleven (11) healthcare facilities operated by MDH. The RFP solicitation number is MDH/OPASS #22-18251. The requirements cover general system features, meaningful use objectives, facility and pharmacy management, order entry and results reporting, clinical decision support, clinical documentation, behavioral health, communications, nursing, providers, therapies, long-term care, infection control, and pharmacy functionality. The contract term is not specified.
The RFP does not provide details on pricing terms, set asides, incumbents, the current environment, funding requirements and sources, or contract amounts. The document focuses on outlining the functional and business requirements for the EHR and revenue cycle management solution that MDH is seeking to procure.
View the file
Other files
Show all 20
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
General-Requirements
| Appendix 4 - Functional and Business Requirements - General Functions |
| SOLICITATION NO: MDH/OPASS #22-18251 |
| Requirement Description |
| 1.0 General System Requirements |
| Please provide a general description of the Offeror’s EHR and Revenue Cycle system. Please indicate the following for each requirement: A=Available in Standard Out of Box |
CP=Available with Custom Programming P = Available from Partner NA = Not Available
| A/CP/P/NA | x.x | EXAMPLE: See example to the left in cell A17 based on the directions above | Description |
| 1.1 | System shall provide a Graphical User Interface (GUI) | ||
| 1.2 | System shall require a secure log in | ||
| 1.3 | System shall support two-factor authentication for secure log-in | ||
| 1.4 | Software shall support at least 12 facilities. | ||
| 1.5 | System shall allow system administrator to define a new facility. | ||
| 1.6 | System administrator shall have the ability to set security levels/permissions by, facility, person, and role (e.g., Physician, Nurse, Pharmacist, etc.) | ||
| 1.7 | System administrator shall have the ability to limit access of a user to specific reports, functions and data | ||
| 1.8 | System administrator shall have the ability to configure roles through a GUI | ||
| 1.9 | Acronyms and abbreviations used by the system shall be able to be added and/or excluded from use by system administrators at each facility, for instance to exclude some commonly used medical terminology abbreviations to avoid confusion. | ||
| 1.10 | User shall have the ability to apply updates to subscription-based services (such as reference databases) without Contractor’s assistance. | ||
| 1.11 | System shall utilize and maintain current diagnosis code classification systems, including but not limited to ICD 10 and DSM 5. System shall stay abreast of diagnosis code classification systems for duration of Contract. | ||
| 1.12 | System shall provide on-line help for standard functions | ||
| 1.13 | System shall provide a complete audit trail for all transactions so that system administrators can identify who added or changed any data in the system and when the addition/change was made | ||
| 1.14 | System shall provide a mechanism for expunging records according to State Law. These records must be deleted but retained in a manner that is sealed but still accessible. | ||
| 2.0 Meaningful Use Description | |||
| Please describe the capabilities of the Offeror’s software to meet the Meaningful Use objectives for Stages 1, 2 and 3. Please indicate the following for each requirement: A=Available in Standard Out of Box |
CP=Available with Custom Programming
| 2.1 | System shall be Certified Electronic Health Record Technology (CEHRT), for the 2015 edition. | |
| 2.2 | System shall meet the 2017 Modified Stage 2 requirements. | |
| 3.0 Maintain Facilities | ||
| 3.1 | System administrator shall have the ability to add/change/inactivate multiple facilities | |
| 3.2 | System administrator shall have the ability to remove anyone with access to the system (e.g., nurses, nurse practitioners, pharmacists, pharmacy technicians, etc.) when, for example, they are no longer employed by the facility. | |
| 3.3 | System administrator shall have the ability to define the different roles, such as prescriber, physician assistant, etc. and the security levels for each role within a facility | |
| 3.4 | System administrator shall have the ability to define multiple units in a facility | |
| 3.5 | User shall have the ability to assign patients to a unit | |
| 3.6 | System administrator shall have the ability to define limit access to confidential patient information, based on user role and relationship to the patient. | |
| 4.0 Reporting | ||
| 4.1 | The system shall generate reports for Meaningful Use attestation. | |
| 4.2 | The system shall generate reports for Quality Measure reporting. | |
| 4.3 | The system shall include Business Intelligence/Analytics capabilities and allow users to create user-defined dashboards. | |
| 4.4 | The system shall generate productivity reports for physicians and other staff. | |
| 4.5 | The system shall permit users to create ad hoc reports, allowing data to be filtered, sorted and manipulated. Data from these reports shall be downloaded into 3rd party applications such as Excel, Access, Crystal Reports, etc. | |
| 4.6 | The system shall provide the ability to use tools to measure the level of depression and the ability to compare scores between intake and discharge. Other measures may later be desired [positive and negative psychosis symptoms]. | |
| 4.7 | The system shall provide the ability to measure treatment outcomes. | |
| 4.8 | The system shall provide the ability to monitor the progress of patients. | |
| 4.9 | The system shall provide the ability to see trends, document and track behavioral health issues. | |
| 4.10 | The system shall have the ability to generate dashboards to monitor quality measures in real-time. | |
| 4.11 | The system shall have the ability to generate dashboards to monitor whether staff has completed their documentation or not. | |
| 4.12 | The system shall provide reports that monitor performance improvement data, such as how well treatment plans are written and changed. | |
| 4.13 | The system shall generate reports regarding discharge projections. | |
| 4.14 | The system shall support incident reporting. | |
| 4.15 | The system shall be able to generate reports to track readmissions, client satisfaction ratings, number of patient injuries and injuries to staff. | |
| 4.16 | The system shall generate reports that help identify patterns, especially with hands-on interventions. | |
| 4.17 | The system shall provide a native mechanism for exporting data to NRI / ORYX. | |
| 5.0 Support Interfaces with Other Systems | ||
| 5.1 | The system shall interface orders and results with an in-house laboratory system. | |
| 5.2 | The system shall interface orders and results with external laboratory systems. | |
| 5.3 | The system shall interface medication orders and provide electronic MARs with external (contracted) pharmacies. | |
| 5.4 | The system shall exchange patient informaiton with the Maryland health information exchange (CRISP). | |
| 5.5 | The system shall exchange patient information with the Maryland county health departments. | |
| 5.6 | The system shall exchange patient information with the Maryland Office of Forensic Services. | |
| 5.7 | The system shall exchange patient clinical information with the Department of Corrections and Public Safety. | |
| 5.8 | The system shall transmit transition of care documents (discharge summaries) when the patient is transferred to another locus of care. | |
| 5.9 | The system shall upload treatment plans, as needed to obtain Medicaid approval. Not applicable in inpatient facilities | |
| 5.10 | The system shall interface with medication dispensing systems, such as Omnicell. | |
| 5.11 | The system interface with medical devices (e.g., glucometers) to obtain and record clinical information. |
RevCycle-Requirements
| Appendix 4 - Functional and Business Requirements - Revenue Cycle | |
| SOLICITATION NO: MDH/OPASS #22-18251 | |
| Requirement Description |
| 1.0 Registration/Admissions/Census Requirements |
| Please provide a general description of the Offeror’s registration/admissions/census system. Please indicate the following for each requirement: A=Available in Standard Out of Box |
CP=Available with Custom Programming
| Desciption | |||
| 1.1 | The system shall maintain a master patient index that is shared with all MDH facilities. | ||
| 1.2 | Financial and clinical information for a patient shall be transferred to the new facility when a patient is transferred. | ||
| 1.3 | The system shall establish a patient profile with photograph and basic information on the patient in case of elopement | ||
| 1.4 | The system shall capture information regarding Living Wills and Advance Directives at patient admission | ||
| 1.5 | The system shall electronically verify insurance. | ||
| 1.6 | The system shall permit the documentation of admission notes (pre-cert, days approved, rate, information from calls to insurance companies). | ||
| 1.7 | The system shall support electronic signature on consent forms and notice of privacy practices (such as on a retail signature pad). | ||
| 1.8 | Insurance information captured from past visits shall be carried forward to new visits. | ||
| 1.9 | The system shall perform electronic eligibility checking and determine if prior authorizations are required. | ||
| 1.10 | The system shall detect registration errors and provide feedback to registrars. | ||
| 1.11 | The system shall support registrar worklists for unverified insurance. | ||
| 1.12 | The system shall support the use of a bed board function to find open beds upon admission. | ||
| 1.13 | The system shall have the ability to attach scanned historical documents to patient record and tagging images with meta data. | ||
| 1.14 | The system shall have the ability to attach PDF documents to the patient record. | ||
| 1.15 | The system shall be able to attach scanned pre-trial work orders, or accept them via interface directly. | ||
| 1.16 | The system shall be able to attach scanned records/documents of medications and other documents (consent, power of attorney, referral forms) upon admission. | ||
| 1.17 | The system shall be able to track patient movement between facilities. | ||
| 1.18 | The system shall be able to track bed availability across facilities. | ||
| 1.19 | The system shall be able to report on ADP (average daily population), length of stays and repeat admissions. | ||
| 1.20 | The system shall support the entry and update of the patient's correct forensic legal status, as well as criminal charges, jurisdiction, hearing dates. | ||
| 1.21 | The system shall support lists of approved/not-approved visitor's for patients. | ||
| 2.0 Patient and Resource Scheduling | |||
| 2.1 | The system shall permit the definition of resources (and times available) into which patients may be scheduled. | ||
| 2.2 | The system shall permit patient scheduling for court , dental, eye, hearing, blood draws, external doctor , imaging exams, etc. appointments. | ||
| 2.3 | The system shall permit the scheduling of recurring patient appointments. | ||
| 2.4 | The system shall permit the rescheduling of patient appointments. | ||
| 2.5 | The system shall permit the user to indicate that the patient was a no-show for an appointment, document the reason for the no-show, and add the appointment to a worklist for rescheduling. | ||
| 2.6 | The system shall support scheduling group sessions and the ability to document arrival and departure times for each patient, as well as individual activities, in the group session. | ||
| 2.7 | The system shall permit a user to view a master schedule for all upcoming appointments. | ||
| 2.8 | The system shall permit a user to view a master schedule for a patient to determine where they are located. | ||
| 2.9 | The system shall track off-grounds hospitalization and outpatient care. | ||
| 3.0 Medical Records | |||
| 3.1 | The system shall provide an e-signature capability for providers to sign off on documents in the patient record. | ||
| 3.2 | The system shall provide Release of Information functions, to log requests, track requests and when fees are paid. | ||
| 3.3 | The system shall notify a provider or the records manager when a release of information has expired and needs to be renewed. | ||
| 3.4 | The system shall support credentialing functions for providers. | ||
| 3.5 | The system will permit staff to check when they will be out of compliance with their credentials. | ||
| 3.6 | The system shall support CPT4 coding, along with ICD-10 and DSM V. | ||
| 3.7 | The system shall work with an encoder and pass back modifiers entered in the encoder. | ||
| 3.9 | The system shall generate productivity reports for medical records staff, quality reports, financial reports (such as the dollar amount that has not yet been coded, a count of particular ICD-10s) and ad hoc reports. | ||
| 4.0 Business Office/Billing | |||
| 4.1 | The system shall automatically generate patient charges based on documented services. | ||
| 4.2 | The system shall support generating per diem charges for patients. | ||
| 4.3 | The system shall create electronic claims and transmit them to either the payor or a clearinghouse. | ||
| 4.4 | The system shall support electronic remittances from all payors (or via clearinghouse). | ||
| 4.5 | The system shall support adjustments to remittances. | ||
| 4.6 | The system shall use worklists for follow-up on denial of service, including the use of rules to direct denials to particular worklists, such as claims as requiring conversion to self-pay, requiring billing to secondary payer, sending accounts to collections or bad debt, etc. | ||
| 4.7 | The system shall support generating aging reports, with buckets for claims aged 30, 60, 90, 120, 150, 180 or higher. |
EHR-Requirements
| Appendix 4 - Functional and Business Requirements - Electronic Health Record | |
| SOLICITATION NO: MDH/OPASS #22-18251 EHR | |
| Requirement Description |
| 1.0 Order Entry / Results Reporting |
| Please provide a general description of the Offeror’s orders and results management module. Please indicate the following for each requirement: A=Available in Standard Out of Box |
CP=Available with Custom Programming
| Description | |||
| 1.1 | The system shall support order entry by physicians/providers (i.e., CPOE). | ||
| 1.2 | The user shall be able to view ongoing medications & medication changes. | ||
| 1.3 | The user shall be able to create diet orders. | ||
| 1.4 | The user shall be able to create consult orders. | ||
| 1.5 | The user shall be able to create orders for imaging tests. | ||
| 1.6 | The system shall assist in consolidating blood draws on lab orders to reduce needle sticks. | ||
| 1.7 | The system shall support the entry of standing orders. | ||
| 1.8 | The system shall suggest lower cost panels when appropriate. | ||
| 1.9 | The system shall detect and alert the user to drug-drug, drug-lab, drug-diet, drug-disease interactions. | ||
| 1.10 | The system shall allow users to create customized order sets and recommend order sets based on diagnosis. | ||
| 1.11 | If order sets are used, the system shall allow monitoring of tasks and dynamic reassignment when needed. | ||
| 1.12 | The system shall provide e-Prescribing functions for discharge and outpatient medications and route the prescriptions to a designated retail pharmacy. | ||
| 1.13 | The system shall transmit medication orders to an external pharmacy and provide eMAR functionality for the medications, once delivered. | ||
| 1.14 | The system shall alert the user to pending medications when an order is discontinued or when the patient is discharged. | ||
| 1.15 | The system shall provide a mechanism to document refused lab orders and send a message to the attending provider. | ||
| 2.0 Clinical Decision Support | |||
| 2.1 | The system shall permit users to create new rules (e.g., alert for septicemia based on subtle changes to labs and vitals). | ||
| 2.2 | The system shall support user-defined decision trees to guide treatment. | ||
| 2.3 | The system shall alert users if a client leaves the program, is discharged or leaves against treatment advice. | ||
| 2.4 | The system shall alert when a required document is due and track whether the documents are complete. | ||
| 3.0 Clinical Documentation | |||
| 3.1 | Users shall be able to select from a library or define and use the following electronic documents: | ||
| 3.1a | Intake assessment (Mental Health) | ||
| 3.1b | Intake forms and enrollment forms, consents, history questionnaires, confidentiality statements/HIPAA forms (mostly completed by clients) | ||
| 3.1c | Incident Report (runaways, property damage, etc.) | ||
| 3.1d | Release of information | ||
| 3.1e | Drug and alcohol assessment | ||
| 3.1f | Functional assessment | ||
| 3.1g | Chemical dependency screening | ||
| 3.1h | Behavioral assessment | ||
| 3.1i | Risk assessments (e.g., suicide risk) | ||
| 3.1j | Initial psych assessment | ||
| 3.1k | Follow-up psych evaluation | ||
| 3.1l | IQ evaluation | ||
| 3.1m | Career interest inventory | ||
| 3.1n | Achievement | ||
| 3.1o | Treatment Plan/medical necessity reviews | ||
| 3.1p | Milieu progress notes in flow chart format for residential 24 hour programs. | ||
| 3.1q | Customized treatment plans relevant to each program | ||
| 3.1r | Discharge Summary | ||
| 3.1s | Other customized documents (i.e., for DAC: interpretative summary, transition plan, discharge planning, treatment contracts) | ||
| 3.1t | Other program-specific documents, unique to a facility | ||
| 3.1u | Charge capture forms, as needed | ||
| 3.1v | New note types, at the agency level. | ||
| 3.2 | Users shall have the ability to document goals, interventions and outcomes in a format that is provider-friendly, is pre-scripted for required Medicaid/quality standards which includes electronic signatures of providers. The system shall include built-in auditing functions for Medicaid required elements. | ||
| 3.3 | The system shall require users, in a progress note, to document a reason why a problem was not addressed during a visit. | ||
| 3.4 | The system shall support chart review to make sure that charting is complete and audits to make sure staff completes their tasks. The system shall flag missing components of a document. | ||
| 3.5 | System shall be able to record data for income/outcome studies of various kinds to include data (such as Beck Depression and Beck Anxiety Inventory scores or OQ 45 scores) for every patient visit and follow up inquiries. | ||
| 3.6 | Users shall be able to create online crisis plans, which describe how to help individual clients when in crisis. | ||
| 3.7 | Users shall be able to log telephone calls and messages, route the entry to the appropriate clinician and associate the entry with a patient’s medical record. | ||
| 3.8 | The system shall support co-signing documents: indicating that a user’s documentation must be co-signed, identifying authorized co-signers, co-signers reviewing, modifying and signing the document, and tracking the disposition of the original document (i.e., how it may be retrieved) once the co-signer has revised and signed the document. | ||
| 3.9 | Users shall be able to create progress notes (with contributions from multiple users), which may include templates or structured documentation, group notes, free text entry, digitized voice, voice-to-text translation. | ||
| 3.10 | The system shall have the ability to incorporate dictated and transcribed documents into patient’s record. | ||
| 3.11 | The system shall have the ability to document status notes for day treatment or residential programs aside from the progress notes. | ||
| 3.12 | The system shall have the ability to document diagnosis, time-in and time-out in the progress notes for every service provided. | ||
| 3.13 | The system shall lock documents from further changes when finalized and list subsequent changes as addenda. | ||
| 3.14 | The system shall provide for supervisory auditing of provider encounter/intervention notes. | ||
| 3.15 | Users shall have the ability to use third party screening systems (such as SASSI) and attach the results to a patient's record. | ||
| 3.16 | The system shall alert users if an assessment or other document is upcoming or due. | ||
| 3.17 | Users shall be able to document permission for patient to go off grounds. | ||
| 3.18 | The system shall support the creation of comprehensive weekly notes, then require subsequent notes every 30 days. The system shall also support other noting patterns such as CRP notes. | ||
| 3.19 | The system shall support interim contact notes (e.g., phone calls with patient's family). | ||
| 3.20 | The system shall support the documentation of group notes, identifying attendees and documenting both group and individual notes, and tracking whether or not the document was completed. | ||
| 3.21 | The system shall support the documentation of social workers. | ||
| 3.22 | The system shall support the documentation of consult notes. | ||
| 3.23 | The system shall support the documentation of mental health exams. | ||
| 3.24 | The system shall support the documentation of interdisciplinary assessments, where each discipline contributes specific content. | ||
| 3.25 | The system shall prompt for required documentation and communicate to alert others as a result of certain events (e.g., AWOL, suicide risk) | ||
| 3.26 | Users shall have the ability to copy forward and edit previous documents rather than recreating from scratch each time. | ||
| 3.27 | The system shall pre-populate documents with information that has already been entered for the patient. | ||
| 3.28 | The user shall be able to document patient injuries, nutrition, speech/audiology notes, dental notes. | ||
| 3.29 | Users shall be able to document a Seclusion Prevention Plan within the Treatment Plan. | ||
| 3.30 | The system shall support the creation of the Patient Incident Reporting System (PIRS), used for assault, seclusion, injuries, restraints. The user shall create the report once and tag each party involved (patients and staff). | ||
| 3.31 | The system shall support the creation of discharge summary, prompting for and generating patient education materials. | ||
| 3.32 | During discharge processing, the system shall list patient service referral agencies that may be appropriate for the patient and notify the agency. | ||
| 3.33 | The system will support documentation based on deviations from the norm (exception-based charting) | ||
| 3.34 | The system shall provide a mechanism for correcting errors in the medical record (e.g., a note documented in the wrong patient's chart). | ||
| 3.35 | The system shall support refreshing treatment plans on a schedule that varies based on the patient's age. (Patients who are over 18 but under 22 must have their treatment plans refreshed every 28 days after they have been admitted for 8 weeks. Older adults only need their treatment plans refreshed every 56 days after the first 8 weeks of an admission). | ||
| 4.0 Behavioral Health | |||
| 4.1 | Users shall be able to select from a library of pre-built treatment plans, create a new treatment plan to add to the library and modify a standard treatment plan for a patient. | ||
| 4.2 | Users shall have the ability to create different styles of treatment plans relevant to different facilities. | ||
| 4.3 | Treatment plans shall drive the capture of required documents throughout the course of treatment. | ||
| 4.4 | The system shall alert when a treatment plan is due, when a treatment review is due, when a medical necessity review is needed and/or when a prior authorization must be completed. | ||
| 4.5 | The system will have the ability to chart based on a depression scale, and create an assessment of patient functioning. | ||
| 4.6 | Users shall be able to document a risk assessment for mental health. | ||
| 5.0 Communication | |||
| 5.1 | The system shall enable communications with other physicians - messaging from provider to provider. | ||
| 5.3 | The system system shall enable communications for transitions of care between the facility and external providers. | ||
| 5.4 | The system shall enable provider communications with consulting physicians. | ||
| 5.5 | The system shall route clinical documentation to others for review and signature. | ||
| 5.6 | The system shall notify other service providers of the high risk status of clients. | ||
| 5.7 | The system shall support communications between other staff (e.g., Patient X had a fight). | ||
| 5.8 | The system shall be capable of communicating that a patient refused lab tests. | ||
| 5.9 | The system shall support communication between disciplines and pharmacy. | ||
| 5.10 | The system shall support communication with county health departments. | ||
| 6.0 Nursing | |||
| 6.1 | Nurses shall be able to view patient list by unit (census) | ||
| 6.2 | Nurses shall be able to view order status – view when the performing department has started and completed processing of order. | ||
| 6.3 | The system shall enforce hard stops in clinical documentation to make sure required elements are captured before allowing the user to continue. | ||
| 6.4 | The system shall support infusion documentation. | ||
| 6.5 | Nurses shall be able to enter notes on patients (e.g., “patient does not take medication as directed, so BP 200/100 is normal for them”). | ||
| 6.6 | Nurses shall be able to Chart against treatment plan so the physician can see what has been done | ||
| 6.7 | Nurses shall be able to view patient history and maintain problem list. | ||
| 6.8 | Nurses shall be able to review and document allergies, differentiating between allergies (e.g., penicillin hives 15 years ago) and sensitivities (e.g., haloperidol neck pain). | ||
| 6.9 | Nurses shall be able to chart vitals and pain scale. | ||
| 6.10 | The system shall enforce required entry of vitals and weight by nurse. | ||
| 6.11 | Nurses shall be able to enter and view bowel data, sleep data, blood pressure. | ||
| 6.12 | The system shall permit nurses to document and view acuity rating in realtime. | ||
| 6.13 | The system shall support body mass index and growth charts. | ||
| 6.14 | The system shall provide graphical display of vital signs (temp, BP, glucose, etc.). | ||
| 6.15 | The system shall generate real time alerts for floor staff and MDs for vital sign trends. | ||
| 6.16 | The system shall support electronic flowsheets, populated by medical devices, with the ability to pull aggregate data and graph vitals over time. | ||
| 6.17 | Nursing orders shall flow to the nurse worklist. | ||
| 6.18 | The system shall provide dashboards of patient status. | ||
| 6.19 | The system shall provide automated nurse tasks that recur (e.g., restraints). | ||
| 6.20 | Nurses shall be able to view all orders for all patients. | ||
| 6.21 | The system shall simplify the medication reconciliation process between nurses and physicians. | ||
| 6.22 | The system's bar code medication administration capabilities shall support verifying the “five-rights”, and be used for vaccines, IV medications, antibiotics or other high alert medications as defined by the facility. | ||
| 6.23 | The system shall alert when medications are overdue. | ||
| 6.24 | The system shall alerts for falls risk, dentures, etc. to minimize risk. | ||
| 6.25 | The system shall generate reports such as admits/discharges by day by unit, staffing by day by unit. | ||
| 7.0 Providers | |||
| 7.1 | Providers shall be able to view lab, xray results, nursing notes. | ||
| 7.2 | Providers shall be able to view the complete patient history including associated documents and results, allergies, problems and medications, with sufficient comment space to state the specific problem for each medication. | ||
| 7.3 | The system shall provide for order tracking. | ||
| 7.4 | The system shall provide for the use of evidence-based order sets. | ||
| 7.5 | Providers shall have the ability to e-prescribe for equipment as well as medications. | ||
| 7.6 | Providers shall be able to update the problem list from all points of care. | ||
| 7.7 | Providers shall be able to indicate that problems have been resolved (as of a specific date) or are chronic. | ||
| 7.8 | Providers shall be able to remove old items from problem list. | ||
| 7.9 | The system shall use the DSM – V – guidelines for codes, and providers shall be able to use drop down or checkboxes to suggest codes. | ||
| 7.10 | The system shall provide suggestions for ICD-10 coding. | ||
| 7.11 | Providers shall be able to use templates for physician documentation, including the ability to use templates created by others, as well as create templates as you go. | ||
| 7.12 | Providers shall be able to use mnemonics that expand to full sentences, phrases, paragraphs when documenting. | ||
| 7.13 | The system shall use what has been documented to drive coding. | ||
| 7.14 | The system shall enable speech-to-text systems to be used to supplement documentation. | ||
| 7.15 | The system shall identify discrepancies on physician chart notes and then route the chart note back to the provider for correction. | ||
| 7.16 | The system shall provide for an audit trail on chart notes, such as where faxes were sent. | ||
| 8.0 Therapies | |||
| 8.1 | The system shall provide for referrals, consults, and scheduling functions for OT/ST/PT/RT, and recreational therapy. | ||
| 8.2 | The system shall support the complete workflow, from physician order, pre-authorization, recurring visit scheduling and clinical documentation. | ||
| 8.3 | The physician shall be able to electronically certify and sign plan of care for patients. | ||
| 8.4 | The system shall track when re-evaluations are due with physicians. | ||
| 8.5 | Providers shall be able to order respiratory therapy and medication on the same order. | ||
| 8.6 | The system shall notify a respiratory therapist that a new order has been entered while they are already on the patient floor. | ||
| 8.7 | The system shall support worklists by therapist and having the order frequency drive the schedule (e.g., 4 times per day). | ||
| 8.8 | Therapists shall be able to document progress notes | ||
| 8.9 | The system shall permit charting the Abnormal Involuntary Movement Scale (AIMS). | ||
| 8.10 | The system shall support pre-packaged documentation templates for therapists | ||
| 8.11 | The system shall use the therapist worklists to create a tickler list when tasks are due. | ||
| 8.12 | The system shall automatically charge medical billing based on treatment times, services provided, etc. | ||
| 8.13 | The system shall permit therapists to code visits (using bundling and modifiers). | ||
| 8.14 | The system shall link treatment codes and diagnosis codes. | ||
| 8.15 | The system shall require PT assistants to have a PT signoff after six visits with the same patient. | ||
| 8.16 | The system shall require co-signing notes, which are required for student therapists. | ||
| 8.17 | The system shall be able to attach third party patient education material, based on diagnosis or problem list, to progress notes. | ||
| 8.18 | Therapists shall have the ability to send messages to providers that become a part of the medical record. | ||
| 9.0 Long Term Care | |||
| 9.1 | The system shall pre-populate the Minimum Data Set (MDS) with patient information | ||
| 9.2 | The system shall facilitate completion of the MDS data by the MDS coordinator | ||
| 9.3 | The system shall transmit MDS data to Medicare/Medicaid. | ||
| 10.0 Infection Control | |||
| 10.1 | Users shall be able to view microbiology results for positive cultures, follow patients with central line/catheter, and receive alerts if patient has MRSA or C. Diff (now or previously). | ||
| 10.2 | The system shall provide real-time alerts to positive microbiology results for certain bacteria. | ||
| 10.3 | The system shall be able to identify high risk patients – those with catheters, central lines, etc. | ||
| 10.4 | The system shall utilize clinical decision support rules that can check clinical indications (fever, chills, nausea, vomiting, etc.) and flag patients that should be checked for malaria, tuberculosis, etc. | ||
| 10.5 | The system shall be able to place a permanent alert on patients that have been colonized with antibiotic resistant bacteria (MRSA, C. Diff, etc.). | ||
| 10.6 | The system shall support telepsychiatry through the use of scheduling and documentation of telepsychiatry sessions. |
Pharmacy-Requirements
| Appendix 4 - Functional and Business Requirements - Pharmacy | |
| SOLICITATION NO: MDH/OPASS 22-18251 | |
| Requirement Description |
| 1.0 General Pharmacy Requirements |
| Please provide a general description of the Offeror’s pharmacy module. Please indicate the following for each requirement: A=Available in Standard Out of Box |
CP=Available with Custom Programming
| Description | |||
| 1.1 | System shall supply and/or integrate third party databases commonly used for order entry systems (e.g., pharmaceutical databases). | ||
| 1.2 | System shall maintain multiple work queues, such as "orders waiting for approval", "orders waiting to be filled", and "suspended orders". | ||
| 1.3 | System shall utilize the metric system (e.g., for patient weight and medication dosing). | ||
| 2.0 Maintain Pharmacy | |||
| Please describe the capabilities of the Offeror’s software to define and maintain pharmacy information. Please indicate the following for each requirement: A=Available in Standard Out of Box |
CP=Available with Custom Programming
| Description | |||
| 2.1 | System administrator shall have the ability to add/change/inactivate a pharmacy. | ||
| 2.2 | System administrator shall have the ability to assign multiple facilities to one pharmacy. | ||
| 3.0 Maintain Facilities | |||
| Please describe the capabilities of the Offeror’s software to define and maintain facility information. Please indicate the following for each requirement: A=Available in Standard Out of Box |
CP=Available with Custom Programming
| Description | |||
| 3.1 | System administrator shall have the ability to define multiple standard medication administration times by facility or unit. | ||
| 3.2 | System administrator shall have the ability to define facility-specific default dispensing quantities based on facility's cassette filling cycle. | ||
| 3.3 | System administrator shall have the ability to identify which days medication orders for each unit are processed in the facility's filling cycle. | ||
| 3.4 | System administrator shall have the ability to turn off or on label printing by facility and type of medication order (e.g., new or renewal). | ||
| 3.5 | System administrator shall have the ability to define a standard set of medication orders by facility. | ||
| 3.6 | System administrator shall have the ability to define medication order pharmacist intervention categories by facility. | ||
| 4.0 Maintain Formulary | |||
| Please describe the capabilities of the Offeror’s software to define and maintain formulary information. Please indicate the following for each requirement: A=Available in Standard Out of Box |
CP=Available with Custom Programming
| Description | |||
| 4.1 | System administrator shall have the ability to add & change a formulary by facility. | ||
| 4.2 | System administrator shall have the ability to inactivate an item in the formulary. | ||
| 4.3 | System administrator shall have the ability to maintain the cost of each item in the formulary | ||
| 4.4 | User shall have the ability to maintain the AHFS code for each medication in the formulary. | ||
| 4.5 | System administrator shall have the ability to define PAR levels for each item in the formulary . | ||
| 4.6 | System administrator shall have the ability to define facility-specific maximum order intervals to be established for each formulary drug, such as limiting a pain medication to 7 calendar days. | ||
| 4.7 | System administrator shall have the ability to define standard order sets for some drugs, such as a tapered dosing schedule for Prednisone or a Medrol dose pack. | ||
| 4.8 | System administrator shall have the ability to define which drugs should not be included in the fill list, by facility. | ||
| 4.9 | System administrator shall the ability to define which drugs are kept in the night cabinet. | ||
| 5.0 Maintain Patient Data | |||
| Please describe the capabilities of the Offeror’s software to define and maintain patient data. Please indicate the following for each requirement: A=Available in Standard Out of Box |
CP=Available with Custom Programming
| Description | ||
| 5.1 | User shall have the ability to maintain patient profiles. Patient data requirements are listed in Appendix 3. | |
| 5.2 | System shall have the ability to store and maintain a photo of each patient for identification purposes. | |
| 5.3 | User shall have the ability to add a free form comment to the patient record. | |
| 5.4 | User shall have the ability to maintain multiple current diagnoses information, including psychiatric and medical diagnoses. After initial diagnosis, information may be updated in the pharmacy module. | |
| 5.5 | System shall record the date and time each diagnosis is added or changed for a patient. | |
| 5.6 | System shall maintain unlimited diagnoses history for all patients. |
| 5.7 | User shall have the ability to view all diagnoses history, including diagnosing prescriber and date. |
| 5.8 | User shall have the ability to associate at least two prescribers with every patient (Patients have a psychiatric and somatic prescriber). |
| 5.9 | User shall have the ability to maintain patient drug allergy and adverse reaction information with date and time that reaction was noted. | |
| 5.10 | User shall have the ability to define and maintain user-defined patient data. | |
| 5.11 | User shall have the ability to transfer a patient and their medication orders to a different unit within the same facility. | |
| 5.12 | User shall have the ability to transfer a patient to a different State facility already defined in the system. | |
| 5.13 | User shall have the ability to identify that a patient is on a "leave of absence". | |
| 5.14 | User shall have the ability to identify patients responsible for administering their medication to themselves under the guidance of the nursing staff (self-med). The "self-med" medications are dispensed slightly differently than the standard medications at each facility. | |
| 5.15 | System shall maintain a history of weight changes. | |
| 5.16 | System shall maintain history of patient with multiple admissions and discharges. | |
| 5.17 | System shall allow an infinite number of medication orders. | |
| 5.18 | User shall have the ability to view history of all patient data, including admissions, discharges, diagnoses, weight, and medication orders. | |
| 5.19 | User shall have the ability to print labels for cassette drawers with patient name, identifying number and unit on demand for one patient or one unit. | |
| 6.0 Process New Medication Orders | ||
| Please describe the capabilities of the Offeror’s software to add and process new medication orders. Please indicate the following for each requirement: A=Available in Standard Out of Box |
CP=Available with Custom Programming
| Description | ||
| 6.1 | User shall have the ability to add and change a new medication order. | |
| 6.2 | System shall provide the ability for multiple roles (e.g., prescriber, pharmacist, pharmacy technician) to add/change a medication order. | |
| 6.3 | System shall provide the ability for user to add a medication order, which then requires prescriber approval before being sent to the pharmacist. | |
| 6.4 | User shall have the ability to maintain user-defined fields on a medication order. For example: A field that user can select if the drug is intended for psychotic use, or a field to direct the nurse to record patient's response to the first dose of a new medication. | |
| 6.5 | User shall have the ability to document a pharmacist intervention on an order, with, at a minimum, user initiating intervention, date/time, category of intervention and detailed comments (free form note). | |
| 6.6 | User shall have the ability to add additional comments to an existing intervention. | |
| 6.7 | System shall automatically record user and date/time of each comment made on an intervention. | |
| 6.8 | User shall have the ability to view all free-form notes on a medication order. | |
| 6.9 | User with the ability to see free-form notes shall have the ability to print free-form notes on a medication order in chronological order with the most recent note first. | |
| 6.10 | User shall have the ability to suspend a medication order. | |
| 6.11 | User shall have the ability to easily identify medication orders which are currently suspended. | |
| 6.12 | System shall provide the ability for pharmacist to be able to notify a prescriber of any concerns about a particular medication order prior approval. | |
| 6.13 | User shall have the ability to record intervention (communication regarding issue with an order), including date and time, pharmacist, physician and nature of issue. | |
| 6.14 | System shall default the start date for a medication order to the current date, but allow the user to override the start date to either a future or past date, no more than 28 days from the current date | |
| 6.15 | System shall default a dispensing quantity for each order based on the facility's defined filling cycle; pharmacist should be able to override the default quantity. | |
| 6.16 | User shall have the ability to identify the time of day for first dose. | |
| 6.17 | User shall have the ability to process a medication order that has a non-standard administration time. | |
| 6.18 | User shall have the ability to look up drugs by mnemonic, generic or brand name. | |
| 6.19 | For each method of looking up drugs, system shall provide partial name look up (leading characters). | |
| 6.20 | For partial name look up, system shall present a list of matches from which the user can select a drug. | |
| 6.21 | System shall display a list of all dosage strengths and dosage forms available in the formulary for a selected drug and allow the user to create the medication order. | |
| 6.22 | System shall require the user to enter a dosage, quantity, administration frequency (SIG code) for each medication ordered. | |
| 6.23 | System shall automatically check to see if any of the prescribed doses or frequency are out of normal range for the patient and notify user with a warning before medication is dispensed. | |
| 6.24 | System shall check to see if any of the prescribed medications are therapeutically duplicate with other currently prescribed medications, indicating those that in the same therapeutic class and notify user with a warning. | |
| 6.25 | System shall provide the ability to translate tapered medication orders into the proper fill orders for each day. | |
| 6.26 | User should be able to select a standard order set, then modify it if necessary. | |
| 6.27 | User shall have the ability to process patient orders for floor stock items. | |
| 6.28 | User shall have the ability to process patient orders for bulk items. | |
| 6.29 | User shall have the ability to record patient-supplied medications, such as herbal supplements. | |
| 6.30 | User shall have the ability to record orders for IV medication. |
| 6.31 | User shall have the ability to process orders with a variety of administration requirements, including 3 weeks. |
| 6.32 | User shall have the ability to process patient medication orders in unit doses |
| 6.33 | User shall have the ability to fill patient medication orders with up to 30 day supply of medications |
| 6.34 | User shall have the ability for the pharmacist to perform ad hoc dispensing of any medication for which a patient has an active order (such as for missing dose and other requests) |
| 6.35 | User shall have the ability to process medication orders for drugs without a National Drug Code ( NDC), such as compounded drugs or investigational drugs |
| 6.36 | User shall have the ability to add & process user-defined SIG codes |
| 6.37 | System shall translate standard dosing scheduling acronyms to specific times consistent with facility's medication administration practice (e.g., B.I.D., H.S.) |
| 6.38 | System shall require pharmacist approval before a medication order is filled |
| 6.39 | System shall provide the ability for the pharmacist to remotely review and approve medication orders |
| 6.40 | System shall verify that each ordered medication is in the formulary for the facility |
| 6.41 | User shall have the ability to view all drugs in the facility's formulary at medication order entry and physician approval. |
| 6.42 | User shall have the ability to view drugs included in Medicaid's Preferred Drug List (PDL) and Medicare's Preferred Drug Program (PDP) for Maryland at medication order entry and approval. |
| 6.43 | System shall automatically convert any medication order written for a brand name drug to the generic equivalent that is included in the formulary and notify user that a substitution has been made. |
| 6.44 | System shall automatically check for drug-to-drug interactions when user enters a medication order and when pharmacist approves the order and notify user with a warning. |
| 6.45 | System shall automatically check for drug allergies when user enters a medication order and when pharmacist approves the medication order notify user with a warning. |
| 6.46 | System shall automatically check for drug-food interactions when user enters a medication order and when a pharmacist approves the order and notify user with a warning. |
| 6.47 | System shall automatically check for minimum and maximum dosage and notify user if dosage is out of normal range. |
| 6.48 | System shall provide online references for drug interactions and food interactions within the order entry process. For example, when the system displays a warning about a drug-drug interaction, the user should be able to access detailed information about the issue. |
| 6.49 | System administrator shall have the ability to add user-defined alerts, such as a reminder to order a lab test when a specific drug is ordered. |
| 6.50 | System administrator shall have the ability to turn off selected warnings. |
| 6.51 | User shall have the ability to override all warning messages. |
| 6.52 | User shall have the ability to access patient lab results at time of order entry. |
| 6.53 | User shall have the ability to dispense drugs based on NDC or GSN. |
| 6.54 | System shall utilize Tall Man lettering for drug selection and printing as needed as defined by Institute for Safe Medical Practices (ISMP) and each facility |
| 6.55 | System shall provide safety checks for Look-Alike/Sound-Alike drug names, error prone abbreviations, symbols and dose designations, and high alert medications. (These may be user-defined warnings set by each facility.) | |
| 6.56 | System shall allow for multiple user defined warnings/information which display when a drug or combination of drugs is ordered. | |
| 6.57 | System shall access cost data and suggest an alternative for a high-cost medication when an order is entered and approved based on facility/BHA formulary. | |
| 6.58 | User shall have the ability to alert prescribers regarding drug therapy concerns via email or other preferred method, such as for drug shortages or therapeutic substitutions. | |
| 6.59 | System shall generate dispensing labels for medications, if requested. Labels shall be compliant with all laws and regulations. | |
| 6.60 | User shall have the ability to print different size labels. | |
| 6.61 | User shall have the ability to print labels with and without full directions. | |
| 6.62 | User shall have the ability to print warnings labels associated with the drug being dispensed, such as "May cause drowsiness", or "Take with food". | |
| 6.63 | System shall provide the ability to print labels on a thermal or similar printer. | |
| 6.64 | System shall provide the ability to print a unique auto-assigned prescription number on a label, if requested. | |
| 6.65 | User shall have the ability to maintain data on medication errors. | |
| 6.66 | System shall record when a drug is dispensed to a patient either individually or in a cassette fill list | |
| 6.67 | System shall maintain a dispensing log record for each medication order dispensed. The dispensing log record shall be maintained for a minimum of five (5) years | |
| 7.0 Discontinue a Medication Order | ||
| Please describe the capabilities of the Offeror’s software to discontinue medication orders. Please indicate the following for each requirement: A=Available in Standard Out of Box |
CP=Available with Custom Programming
| Description | |||
| 7.1 | User shall have the ability to discontinue an existing medication order. | ||
| 7.2 | User shall have the ability to discontinue a medication order on a future date. | ||
| 7.3 | User shall have the ability to view all medication orders for a patient and filter by order status (active, discontinued, expired). | ||
| 7.4 | User shall be able to select a medication order to discontinue from a list of all active orders. | ||
| 7.5 | User shall have the ability to return medication and record return to patient's account, along with the date of the return. | ||
| 8.0 Process Existing Medication Orders | |||
| Please describe the capabilities of the Offeror’s software to process existing medication orders. Please indicate the following for each requirement: A=Available in Standard Out of Box |
CP=Available with Custom Programming
| Description | |||
| 8.1 | User shall have the ability to generate fill lists for active medication orders by unit or facility. | ||
| 8.2 | User shall have the ability to generate fill lists on demand that contain only changes. | ||
| 8.3 | User shall have the ability to generate duplicate fill lists on demand that do not alter inventory or post charges. | ||
| 8.4 | System shall provide the ability for pharmacist to override the number of days to be dispensed for a unit before the fill list is generated. | ||
| 8.5 | User shall have the ability to remove an order from the fill list for the patient. | ||
| 8.6 | User shall have the ability to identify patients going on "leave of absence" to fill medication orders for the duration of the leave. | ||
| 8.7 | User shall have the ability to identify patients on leave of absence to not fill in-patient orders while on leave. | ||
| 8.8 | User shall have the ability to identify patients on "self-med" and fill orders as per facility policy. | ||
| 8.9 | For orders filled as a 30 day supply, system shall generate a report of all medication orders which are due to be refilled by facility, unit or patient. | ||
| 9.0 Renew Medication Orders | |||
| Please describe the capabilities of the Offeror’s software to renew medication orders. Please indicate the following for each requirement: A=Available in Standard Out of Box |
CP=Available with Custom Programming
| Description | |||
| 9.1 | System shall provide the ability to identify medication orders that will be expiring by a specified date at one facility, unit, prescriber or patient. | ||
| 9.2 | System shall provide the ability to automatically alert prescriber of all of his/her medication orders that will be expiring by a specified date. | ||
| 9.3 | System shall provide the ability for prescriber to easily review and approve or discontinue expiring medication orders for patients in one unit, at one facility, or all expiring medication orders for one patient. | ||
| 9.4 | User shall have the ability to view all medication orders that are expiring by facility, unit, prescriber, or patient. | ||
| 9.5 | User shall have the ability to view all medication orders for a patient and filter by order status (active, discontinued, expired). | ||
| 9.6 | User shall have the ability to select a medication to renew from a list of existing orders. | ||
| 10.0 Process Floor Stock Orders | |||
| Please describe the capabilities of the Offeror’s software to process floor stock orders. Please indicate the following for each requirement: A=Available in Standard Out of Box |
CP=Available with Custom Programming
| Description | |||
| 10.1 | User shall have the ability to add or change a medication order for one or more floor stock items for a unit. | ||
| 10.2 | User shall have the ability to view history of floor stock orders by unit. | ||
| 10.3 | User shall have the ability to reorder prior floor stock order. | ||
| 10.4 | User shall have the ability to print a sign off sheet or label for a sign off sheet for controlled medications sent to the unit. Sheets must contain a unique tracking number and be customizable by unit. | ||
| 11.0 Process Medication Reconciliation | |||
| Please describe the capabilities of the Offeror’s software to reconcile medications for a newly admitted patient. Please indicate the following for each requirement: A=Available in Standard Out of Box |
CP=Available with Custom Programming
| Description | |||
| 11.1 | User shall have the ability to record medication orders from a previous facility when a patient is admitted. | ||
| 11.2 | System shall provide the prescriber the ability to view medication orders from a prior facility and select (and modify) those to be continued. | ||
| 12.0 Process Inventory | |||
| Please describe the capabilities of the Offeror’s software to process and maintain pharmacy inventory. Please indicate the following for each requirement: A=Available in Standard Out of Box |
CP=Available with Custom Programming
| Description | |||
| 12.1 | User shall have the ability to record delivery receipt of drugs from wholesaler by facility. | ||
| 12.2 | System shall automatically remove medication quantities from a pharmacy's inventory when they are dispensed. | ||
| 12.3 | User shall have the ability to put returned medications back into inventory. |
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 .