80TECH24Q0023 Enclosure 4 - Objective Statements (00003).pdf

PDF 160 KB Posted

Attached to
Johnson Space Center (JSC) Electronic Health Record (EHR) Replacement
Solicitation number
80TECH24Q0023
Issued by

About this file

This document appears to be Enclosure 4 - Objective Statements for a Request for Quotation (RFQ) for the Johnson Space Center (JSC) Electronic Health Record (EHR) Replacement. The key details are:

The contractor shall propose and implement an efficient data migration plan to securely and accurately transfer existing clinical data, forms, and hyperlinks to the integrated platform. The contractor must describe how the EHR software solution can interface with JSC's technical environment, including system integration capabilities, security integration, and connections with US-based and international partners. The contractor shall describe various clinical support and decision-making features of the EHR software, such as decision support tools, imaging order management, lab test result displays, and customizable workflows. The contractor shall detail the operational support and maintenance activities, including deployment, training, monitoring, and reporting. Additionally, the contractor must address specific requirements for managing astronaut health data, such as maintaining ICD-9/ICD-10 codes, medical reconciliation, military medical record integration, and behavioral health data compartmentalization.

The related federal contract opportunity is Solicitation #80TECH24Q0023 for the JSC EHR Replacement. Offers are due by 4:00 PM EDT on July 26, 2024, and the Government will award a Best Value Trade-Off contract.

View the file

Other files

Show all 18

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

ENCLOSURE 4 RFQ# 80TECH24Q0023 (00003)

Enclosure 4 Objective Statements

For

Johnson Space Center (JSC) Electronic Health Record

(EHR) Replacement

1.0 Objective Statements

1.1 Data Management and Integration

1.1.1 Data Integrity and Migration

1.1.1.1 Comprehensive Data Migration Plan

The contractor shall propose and implement an efficient data migration plan that adheres to industry standards and best practices to ensure the secure and accurate transfer of existing clinical data, forms, and hyperlinks to the integrated platform. This encompasses patient records, diagnostic information, and historical data, with a meticulous approach to data cleansing and validation to maintain data integrity throughout the migration process. This will include highly sensitive charts and documentation with administrator permission-based access. The plan shall include process descriptions, diagrams, procedures, and quality assurance controls.

1.1.1.2 Data Integrity Assurance

The contractor shall propose a plan that ensures data integrity within the JSC Clinic.

This includes handling errors in data aggregation, dataset creation, management processes, and throughout the ETL (Extract, Transform, Load) operations. The goal is to ensure data integrity with minimal need for additional coding or configuration, highlighting the complexity of the task and the need for the contractor’s expertise.

1.1.1.3 Data Validation and Integrity Checking Support

Much of the data captured by the JSC EHR is provided to researchers and must meet strict standards. JSC employs data validation and integrity checking to ensure data quality. For example, Norm, NORM, and Normal must be homogenized into one universally recognized term indicating a normal response or triggering an alert to prompt a compliant response. The contractor shall describe how this data validation and integrity checking is supported in their solution, including compliance with JACHO terminology.

1.1.2 Interfacing and System Integration

1.1.2.1 System Interface Needs

The contractor's proposal and implementation of an EHR software solution that meets NASA's system interface needs is of utmost importance. JSC relies heavily on BizTalk to manage communication and exchange data with external providers, lab instruments, medical devices, systems, and remote entities. Multiple non-BizTalk system interfaces are also in place. The contractor shall describe how the EHR software solution included as part of its quote can utilize formats listed in the requirements to replicate connections shown in the diagrams provided. If not utilizing BizTalk, the contractor shall include a description of its ability to utilize an innovative approach to functionally replace the listed connections with an interface solution and what is required (ex. time and level of IT expertise) for NASA IT support to learn to build, operate, and maintain interfaces in this proposed interface solution. If the contractor’s quote includes the use of BizTalk as an interface engine, details shall be included reflecting interface options that can be implemented prior to BizTalk’s projected end of life in 2028.

1.1.2.2 Technical Environment and Security Integration

Government requirements are identified throughout the SOW and in the attached documents. The contractor shall describe their EHR software solution’s ability to seamlessly integrate into our technical environment and security processes as required, providing Multi-Factor Authentication capability, including descriptions of Identity and Access Management and Single Sign On capabilities.

1.1.2.3 Connection with US-based and International Partners

The contractor shall describe how all connections with US-based and international partners are securely and efficiently established and monitored, including alerting and reporting.

1.1.2.4 Patient Portal with Secure Messaging

The contractor shall describe how its EHR software solution provides a patient portal and secure messaging services described in the Scope of Work section, including details on capabilities such as file size and type, character counts, and other characteristics and features, such as the ability to handle surveys, questionnaires, forms, notes, and conversations and import them into the patient record. The contractor shall describe the steps of the process for these items to be imported and become part of the medical record. (Ex, how to take a secure messaging string and turn it into a patient encounter.)

1.1.2.5 Report Management and Data Mapping

The contractor shall describe how the EHR software solution ingests standard and custom reports via fax, secure messaging, and other electronic means and then maps the data to its appropriate locations within the EHR.

1.2 Software Features and Capabilities

1.2.1 Clinical Support and Decision-Making

1.2.1.1 Clinical Decision Support Tools

The contractor shall describe how its Clinical Decision Support tool within the EHR software solution could be effectively utilized by providers given JSC’s unique, healthy, and well-studied patient population.

1.2.1.2 Diagnostic Imaging Orders

Regarding ONC HIT criteria 170.315 (e)(3) Patient Health Information Capture, the contractor shall describe how its EHR software solution enables a clinical user to record, change, and access diagnostic imaging orders, including a "reason for order" field.

1.2.1.3 Additional EHR Capabilities

Based on the background information provided, the contractor shall describe any additional capabilities within its proposed EHR Software Solution that could be of significant benefit to JSC’s EHR use (example: specifics of voice transcription capabilities). This description should clearly indicate what capabilities are included in the price quoted.

1.2.1.4 Standard Clinical Terminology

The contractor shall describe how its EHR software solution facilitates data searches using standard clinical terminology across patient records without requiring programming or technical knowledge.

1.2.1.5 Lab Tests Results

The contractor shall describe how its EHR software solution acquires lab results and displays normal and abnormal values and ranges and automatically populates flowsheets, including graphical representations of individual test results over time.

1.2.1.6 Report Generation

The contractor shall describe the EHR software solution’s capabilities for running existing, saved reports and for generating custom reports that may become saved reports. Provide details on the reporting functionality's content capabilities, including the ability to produce charts, graphs, trend lines, and other metrics for standard and customized data. These capabilities should be available throughout the system and applicable to any data set.

1.2.1.7 Customizable Workflows

The contractor shall describe how their EHR software solution allows user customizable workflows to meet clinical process needs.

1.2.1.8 Workflow Alerting

The contractor shall describe how their EHR software solution alerts staff and clinicians when tasks are assigned, when forms, applications, certifications, and orders need to be completed or signed, when items are due/overdue, when these alerts are available in relation to patient encounters, if the alerts are automatic or require staff action, and how they are differentiated based on criticality. Explain how these processes can be used for provider cross-coverage and quality monitoring.

1.2.1.9 Workflow Status

The contractor shall describe how staff can easily drill down to see patient encounter progress, including completed and outstanding documents, incomplete reviews, unsigned reports, scheduled and confirmed appointments, and custom steps.

1.2.2 Customization and User Interface

1.2.2.1 Customization of User Interfaces

The contractor shall describe how individuals may customize their user interfaces to support specific roles and tasks. The contractor shall also show how departmental or other tabs may be added to patient charts.

1.3 Operational Support and Maintenance

1.3.1 Deployment and Maintenance

1.3.1.1 Operation and Maintenance Activities

The contractor shall describe the automated and manual support activities that are part of the proposed EHR software solution's daily operation and maintenance, including system analysts' and administrators' time estimates per day for activities such as, but not limited to, software updates/patching, data backups/recovery, system and error monitoring and alerting, compliance and auditing, data entry and quality control, custom reporting, user training and support, system configuration and customization, etc.

1.3.1.2 Support Services and Tiers

The contractor shall describe its support program, services, and tiers, both those that are included and those that are additional costs. Descriptions of support included in the quote and with annual licensing shall be clear and detailed. Clearly separated service details should be included for the support tiers not already included in the proposal.

Service details should outline the contractor’s capability to provide future product support, including addressing issues that could arise from frequent security patching.

1.3.1.3 Training Program

The contractor shall describe its training program included in the implementation cost, identifying role-designed tracks, classes, formats, durations, timing, and tests for understanding. The contractor shall also detail training options available for ongoing support.

1.3.1.4 Deploying and Maintaining the Software

The contractor shall describe the approach and processes for successfully deploying, operating, and maintaining the software, including hotfixes, patches, and upgrades.

Specifically, this includes establishing and maintaining Development, Test, Staging (Integration), and Production environments.

1.3.1.5 On-site Support

Organizing on-site events helps achieve important project milestones and maintains efficient communication and teamwork among project team members. The contractor’s proposal shall include a plan detailing any necessary onsite support for key milestones and tasks being included in the contractor’s proposal.

1.3.2 Performance Monitoring and Reporting

1.3.2.1 Monitoring, Alerting, and Investigating Issues

The contractor shall describe tools included in its EHR software solution to monitor, alert, investigate, troubleshoot, and report on system issues, health, and performance.

1.3.2.2 Determining Requirements

The contractor shall describe the recommended process for determining compute, storage, bandwidth, connectivity, and hardware configuration requirements.

1.4 Patient and Medical Data Handling

1.4.1 Access Controls

1.4.1.1 Locations of Care

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. Additionally, levels of segregation are required where medical providers should be granted access to only a specific patient or group of patients. For example, International Partner medical providers should have access to their respective country’s astronaut medical records, but not the records of astronauts from other countries. The contractor shall describe how its EHR software solution addresses this need.

1.4.1.2 Multiple Charts Per Patient

JSC manages multiple unique and separate charts per patient, fully independent of each other. For example, an astronaut may have Flight Medicine, Selection, and Behavioral Health Program charts, each with unique ID numbers and individual chart role-based access to provide necessary compartmentalization. The contractor shall describe how their EHR software solution can manage multiple chart numbers for a patient, with each chart number having a different level of access and how charts can be merged if necessary. (Example: How could an astronaut candidate’s selection chart be merged with their active astronaut chart or merging an employee’s Occupational Health chart into an active astronaut chart after the employee is selected to be an astronaut.)

1.4.2 Medical and Health Data Management

1.4.2.1 Maintenance of ICD9 and Utilization of ICD10

JSC does not process payments, but we do utilize ICD9, ICD10, and other standard medical codes for recording treatments and supporting healthcare operations disclosures. The contractor shall describe how the proposed EHR software solution maintains support for ICD9 while utilizing ICD10.

1.4.2.2 Handling Astronaut Health Data

In addition to standard healthcare and occupational health services, JSC provides annual executive-level physicals, highly specialized care, features, and functionalities crucial to our mission, especially with our astronaut population. For example, extensive testing is conducted relating to Spaceflight Associated Neuro-ocular Syndrome, space radiation exposure, and other unique occupational hazards astronauts face. Additionally, astronaut health data is collected throughout the astronaut’s lifetime, being utilized to support primary care, lifetime health surveillance, and a wide variety of research. This drives a heavy reliance on user-created customizable forms with numerous high-character custom data fields that are re-usable and can be added to different records.

The contractor shall describe the capabilities of their EHR software solution to address these unique needs including the steps in the process for creating custom forms and custom fields that can be generated once and reused throughout the EHR.

1.4.2.3 Prescription Management

The contractor shall describe the process for a physician to submit a prescription, then recall it and edit it before it is filled, without having to cancel it and submit a new one.

Physicians should also be able to prescribe narcotics by sending prescriptions using EPCS to external pharmacies and by printing those prescriptions to the on-site JSC Pharmacy.

1.4.2.4 Medical Reconciliation

For spaceflight missions, NASA builds mission drug kits that contain standard and compounded medications for multiple astronauts. These are the only medications on-board and while intended to be utilized by the named individuals, they are available to others to address emergent needs. The contractor shall describe its EHR software solution’s capabilities with respect to medical reconciliation, including alerting, custom reporting, and data visualization. The description shall also include capabilities of free text medication name searches that apply to as built mission drug kits and normal pharmacy operations.

1.4.2.5 Tracking Care Team Members

The contractor shall describe the steps required to assign individual care team members to each astronaut, generate a list of current and past care team members, and display or print the list.

1.4.2.6 Management of Astronaut Health Data

Because NASA tracks astronaut health data across their lifetimes, new observation terms need to be added while maintaining support for past observation terms. The contractor shall describe how data integrity and relationships will be maintained as observation terms are added, including maintaining their historical relationships.

1.4.2.7 Integration of Military Medical Records

Over half of our astronaut population is active or retired military and may have multiple medical records that need to be incorporated, in whole or in part, into their NASA medical record. The contractor shall describe how these military medical records would be ingested into the new EHR system, if ingested records would be ingested as searchable data or images of forms and describe how this process is enabled and completed including verification and validation.

1.4.2.8 Military Astronaut Rank

The contractor shall describe how military astronaut rank, branch, and country affiliation are properly and prominently listed in a demographic field within the EHR.

This description shall specify if both US and foreign military rank titles would be available for use.

1.4.2.9 Behavioral Health Data

JSC Behavioral Health and Employee Assistance Program data is separated to avoid any possibility of identification of behavioral health engagement by those without appropriate permissions. This includes references to behavioral health visit notes in an encounter list. The contractor shall describe how it’s EHR software solution controls user access to phycological and behavioral data to afford full compartmentalization and allows authorized users to record and make corrections to social, psychological and behavioral data.

1.4.2.10 Clearance and Certification

NASA requires unique medical clearance for its personnel to conduct certain specific tasks, especially those related to flight and dive certifications. The contractor shall describe how its EHR software solution can support customized medical clearance related data, flag records as currently certified or de-certified, provide alerts when certifications are approaching expiration, and generate and track medical clearance letters and memos.

1.4.2.11 System Log Access

The contractor shall describe how its EHR software solution supports restricted access to system logs and scheduling for data imports and updates.

1.4.2.12 Referrals and Appointments

The contractor shall describe how its EHR software solution creates and manages referrals and appointments, including entering, tracking, and reporting, importing and exporting calendar invites, all based on user role permissions and initiation source.

1.4.2.13 Drug Checking Capabilities

JSC has unique pharmacy needs. In addition to common pharmaceuticals, JSC has a heavy reliance on custom, non-standard formularies, which makes medication reconciliation utilizing standardized medication databases inadequate. The contractor shall describe how its EHR software solution addresses drug-drug interaction and drug allergy checking capabilities as they pertain to custom, non-standard formularies.

1.5 Technical Specifications

1.5.1 The contractor shall describe how it will successfully integrate the proposed EHR software solution into JSCs technical environment, including identifying any specific storage requirements or upgrades to JSCs technical environment that would potentially be required to ensure the EHR will operate in an on-premises implementation.

1.5.2 The contractor shall describe the technical specifications required to operate and maintain its EHR software solution in a cloud-based deployment, including connectivity and bandwidth requirements.

File details come from the government source that posted it. Updated .