Attachment B Demo Script.xlsx
XLSX spreadsheet 23 KB Posted
- Attached to
- RFQ 80JSC025Q7001 Electronic Health Record
- Solicitation number
- 80JSC025Q7001
About this file
This is a demo script file containing detailed requirements for demonstrating an Electronic Health Record (EHR) system's capabilities for NASA's Johnson Space Center. The script outlines five major demonstration areas: Registration/Scheduling, Patient Visit Management, Patient Portal/Secure Messaging, User Interface/Configuration, and Other Administrative Functions.
Key demonstration requirements include: creating and managing multiple patient charts with different access levels, integrated appointment scheduling across multiple providers, secure patient portal functionality, comprehensive clinical documentation capabilities, medication safety analysis, custom reporting, and specialized NASA-specific needs such as astronaut health data management. The script emphasizes requirements for granular access controls, discrete partitioning for multiple locations of care (including Astronaut Selection and International Partners), PACS integration, and custom form creation capabilities. Each requirement is mapped to specific PWS sections, indicating this is supporting documentation for RFQ 80JSC025Q7001 for a new COTS, on-premises EHR solution at Johnson Space Center.
View the file
Other files
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
Refined_Objective_Requirements_
| Objective Requirement | PWS Requirement | ||
| 1 | Registration/Scheduling | Related Points of Interest/Notes | |
| a | Demonstrate creating and editing patient charts | Naming conventions, duplicate chart name alert when creating chart, explain what fields are mandatory during chart creation, can fields be easily added or modified to include special identifiers (military rank, current or former astronaut, flight assigned astronaut, etc.), can test patients be created in the production environment, do test patients carry over to other EHR modules | 3.1.7 |
| b | Demonstrate positioning multiple different provider and department schedules from EHR on a single screen (Integrated Appointment System.) | Current practice is to have system display 10 at time | 3.1.5.2 |
| c | Demonstrate how custom appointment types can be made for patients across multiple providers and department schedules from this single screen. | 3.1.5.2 | |
| d | If centralized schedule management is part of a Practice Management module, show how this functionality can be used without requiring other Practice Management functionality. | 3.1.5.2 | |
| e | Demonstrate how staff is notified of patient check-in including, notification of arrival to clinic staff. | Arrival only. | 3.1.5.2 |
| f | Demonstrate how electronic forms may be received from patients, are securely updated, completed, printed, returned, and imported into or attached to that patient's medical chart | Integration with secure messaging/patient portal; Capability to print these forms/reports. | 3.1.3.2 3.1.3.3 3.1.3.4 |
| g | Demonstrate how the software can manage multiple chart numbers for a patient, each chart number with a different level of access. | JSC requires the capability to establish and maintain multiple active charts for a single patient, each with unique content, different chart numbers, and granular access controls. In some cases, a care provider will be able to see only one of the charts, while others see them all. (For example, compartmentalization of behavioral health information as discussed in the PWS.) Can the existence of a type of chart be totally hidden from providers without access to that chart? Will the charts existence be known but data unaccessible without permissions and if so, could encounter existence be seen by providers without permissions to view the chart? | 3.1.7.1 3.1.7.15 |
| h | Demonstrate how to manage patient portal/secure messaging registrations within the EHR. | How are patients "activated" (clinic and patient sides of the system) | 3.1.3.2 3.1.3.3 3.1.3.4 |
| 2 | Patient Visit Management | Related Points of Interest/Notes | |
| a | Demonstrate how staff can drill down to see patient process progress, including completed and outstanding documents, incomplete reviews, unsigned reports, scheduled and confirmed appointments, and custom steps. | 3.1.5.2 | |
| b | Demonstrate collecting and viewing current and historical results and documentation. | Naming conventions, document types, sorting, etc.; Document views; Custom document type configuration; Custom desktops (Flight Surgeon, Ready for Signature, etc.); Document routing | 3.1.2.7 3.1.2.9 3.1.3 3.1.4.2.4 3.1.7.9 3.1.7.10 |
| c | Demonstrate the process for accessing the patient's record, documenting vital signs, and updating medical history directly into the EHR. | 3.1.7.1 | |
| d | Demonstrate capturing test results and using them to populate chart forms, flow sheets, and alerts. | How does EHR communicate internally, ex Dr wants a lab repeated in a week, how are alerts, pop ups, flags, etc. used. | 3.1.2.10 3.1.2.13 3.1.4.2.4 3.1.7.9 |
| e | Demonstrate how a physician is alerted (email, EHR pop up, etc.) to internal and external forms, applications, and certificates that must be reviewed and signed. | Is the alert an email (or can it be?) How can EHR desktop be customized to allow physicians to easily monitor for alerts? What internal communication options are available (alerts, flags, converting flags to documents, etc.?) | 3.1.2.10 |
| f | Demonstrate how the physician can access comprehensive patient records, review test results, receive alerts and clinical decision support prompts, record diagnosis information, and then build and manage treatment plans. | Clinical Decision Support prompts.Are clinical decision support prompts customizable? | 3.1.2.10 3.1.2.13 3.1.4.2.4 3.1.7.9 |
| g | Demonstrate how a physician documents an encounter. | Include capabilities for custom notes, TextBlob notes, phone notes, etc. as applicable. | 3.1.2.13 3.1.2.14 3.1.7 |
| h | Demonstrate how a physician adds internal notes. | Include capabilities for custom notes, TextBlob notes, phone notes, etc. as applicable. | 3.1.7.1 3.1.7.12 |
| i | Demonstrate how a physician updates information in the patient chart. | Include capabilities for custom notes, TextBlob notes, phone notes, etc. as applicable. | 3.1.2.13 3.1.2.14 3.1.7 |
| j | Demonstrate medication safety analysis and alerting, including drug/drug interactions, drug allergy checking, and notification capabilities using a custom formulary that includes commercial pharmaceuticals, over-the-counter, and compounded drugs. | Entry of standard med/controlled med. Prescriptions are required to be printed to JSC Pharmacy, it is non-networked and unavailable for traditional e-prescribing. | 3.1.2.5 - 3.1.2.9 |
| k | Demonstrate the steps for a physician to organize their user interface view according to their requirements and preferences | 3.1.3.1 | |
| l | Demonstrate the order entry process for the following order types: pharmacy, lab, and clinical tests (EKG, sonogram, etc.) | 3.1.2.12 3.1.2.13 3.1.2.14 |
| 3 | Patient Portal/Secure Messaging | Related Points of Interest/Notes | |
| a | Demonstrate how to send and receive specific components of charts internally and externally. | Forms and results | 3.1.3.2 - 3.1.3.4 |
| b | Demonstrate how the portal can enable and streamline communication between patients and healthcare providers | 3.1.3.2 - 3.1.3.4 | |
| c | Demonstrate how the portal is integrated with the EHR, emphasizing clinic-side controls and security functions | 3.1.3.2 - 3.1.3.4 | |
| d | Demonstrate exchanging documents with patients and external providers using secure messaging before and after appointments | How are documents attached/included into a message. How are messages/documents copied into the chart, which ones are automatic, and which require user input? | 3.1.3.2 - 3.1.3.4 |
| 4 | User Interface/Configuration | Related Points of Interest/Notes | |
| a | Demonstrate options for updating and tracking changes to chart content | 3.1.6.2 3.1.7 | |
| b | Demonstrate how custom and standard reports about chart completeness can be generated and delivered to selected staff | 3.1.4.2.4 | |
| c | Demonstrate the options for creating standard and custom formats for displaying and printing specific data including lab results and patient notes | 3.1.4.2.4 | |
| d | Demonstrate patient-specific alerts and notifications and how visit schedules can be updated and managed. | 3.1.2.10 3.1.3.1 | |
| e | Demonstrate customizable interfaces for desktops, laptops, and handheld devices of all sizes. | 3.1.3.1 | |
| f | Demonstrate making some user interface (UI) components mandatory and some user choice. Show the options for UI settings and user preferences. | 3.1.3.1 | |
| g | Demonstrate creating and managing user-defined and system-defined actionable pop-up reminders. | Difference between administrative vs clinical alerts and high priority vs normal alerts. | 3.1.2.10 3.1.3.1 |
| h | Demonstrate capabilities and limits related to approved system users creating custom forms and structured data fields. Include the processes for creation, placement, and inclusion in data management. Address any limitations on the number of custom forms, fields, and character counts. | Creating and utilizing custom data fields with minimal restrictions allows the NASA to comprehensively collect and manage required astronaut health data that may not be typical for standard EHRs. | 3.1.5.1 |
| i | Demonstrate how to create, import, and export custom orders and order sets for ground-, pre-, inflight-, and post-studies. | 3.1.2.13 | |
| j | Demonstrate how access controls are implemented and managed for multiple locations of care, including chart, form, and data field levels. | NASA supports multiple, unique locations of care and needs the ability to assign custom and role-based access to charts, forms, and data fields based on those locations of care. Refer to PWS for details on locations of care. | 3.1.6.1 3.1.6.2 3.1.7.1 3.1.7.15 |
| k | Demonstrate discrete partitioning for multiple locations of care, including Astronaut Selection, NASA users, International Partners users. | 3.1.7.1 3.1.7.15 | |
| l | Demonstrate PACS integration and access management tools to control access to specific PACS studies and prevent access to all others. | 3.1.1.2.1 3.1.7.1 3.1.9.1 3.1.9.3 | |
| m | Demonstrate building standard, audit, and ad hoc reports using discrete data queried from within the EHR without requiring technical support | 3.1.4.2.4 | |
| 5 | Other | Related Points of Interest/Notes | |
| a | Demonstrate how an admin can suspend or log out a user. | For example, a provider did not log out of the system and is unavailable to do so. | 3.1.1.2.6 |
File details come from the government source that posted it. Updated .