PWS Attachment 1 Specifications 05.30.2023.xlsx
XLSX spreadsheet 43 KB Posted
- Solicitation number
- 36C10B22R0022
About this file
This solicitation requests proposals for the National Teleradiology Program NextGen PACS. Key details include the Department of Veterans Affairs requiring a Picture Archiving and Communication System to handle initial annual study volumes of up to 2 million radiology exams, with expansion potential to 9 million exams. Offerors must design, deploy and support the PACS along with artificial intelligence modules for intracranial hemorrhage identification, large vessel occlusion detection, and breast cancer and density analysis. Proposals are due by September 6, 2022 with award intended for base period performance through November 30, 2023 to fully implement the NextGen PACS and support requirements. The solicitation allows for three potential 12-month option periods for ongoing system sustainment and optimization thereafter.
View the file
Other files
Show all 24
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
Sheet1
| GENERAL SPECIFICATIONS | |
| 1 | The diagnostic PACS viewing application, Intracranial Hemorrhage (ICH) identification, large vessel occlusion (LVO), breast cancer and breast density Artificial Intelligence applications shall have current Food and Drug Administration (FDA) 510(k) certification. |
| 2 | The Contractor shall design, deploy, and support the NTP PACS to handle initial annual study volumes up to 2 million Radiology exams with full activation to be completed no later than 12 months from date of award. Phase 2/Optional Task 1 shall include expansion of up to 7 VISNs and up to 9 million annual exams total. |
| 3 | Upon receipt of a recent unread case within the NTP PACS partition, the system shall issue an automated preliminary “stub” report back to the originating site via HL7v2 message, indicating that the study has been sent to NTP for interpretation. The “prelim” report shall be sent from the PACS within 2 minutes of complete study receipt. |
| 4 | Upon receipt of a preliminary or final HL7v2 encoded report generated by a VA customer site, the study shall automatically be removed from the NTP unread worklist and the system shall prevent NTP interpretation of the study. For sites using NextGen PACS, their worklist shall include a designation that the study was assigned to NTP, but the HL7 message shall still be broadcast to VistA or Cerner for study tracking purposes. |
| 5 | Final signed reports and addendums shall be uploaded by the PACS to the originating site’s VistA or to Cerner OpenLink using HL7v2 results messages. Should a report not successfully upload, the system shall provide notification that corrective action is required. |
| 6 | PACS shall have an integrated Radiologist worklist with study locking across the application in less than 0.5 seconds to prevent duplicate reading. NTP shall have a distinct worklist with designated assignment engine/workflow tools, while VISN PACS shall have the option to set up unique VISN-based or site-based worklists for their use. |
| 7 | The system shall provide seamless API integration with VA/DoD Joint Legacy Viewer (JLV), which requires the use of Clinical Context Object Workgroup (CCOW). This shall include a button or other mechanism to launch JLV directly from within the PACS application, have it pass patient context via CCOW to JLV, and then maintain patient context as different studies are viewed within the PACS (i.e. update CCOW context). |
| 8 | PACS and associated applications shall support application authentication using Single Sign-On (SSO). |
| 9 | The NextGen PACS is a mission critical application that is required to be online 24x7x365. The system shall be designed and deployed with appropriate redundancy and fault tolerance to eliminate single points of failure. The target uptime threshold for the overall system must be 99.99%. The Contractor’s design and technical support infrastructure must meet or exceed that level of performance. System shall be designed for 99.99% uptime as measured by 24x7 availability with performance penalties applied when uptime falls below 99.9% as calculated monthly. Downtime will be defined as failure of one or more components that measurably impacts VA’s ability to receive or interpret studies or transmit reports to the originating EMR. Contractor shall provide NTP and VISNs with a monthly uptime report with adjusted billing of the ongoing service/support cost per the discount rate below. Note that scheduled downtime such as work to complete software upgrades and maintenance is excluded from the downtime calculation. Fail-over and/or test servers shall be used to perform these activities with little or no impact to the clinical operations. |
| ARCHITECTURE AND SECURITY | |
| 10 | System shall be designed and deployed such that it is installed on Medical Device Virtual Local Area Networks (VLANs) and behind Access Control Lists (ACLs) or firewalls. |
| 11 | For all contractor deployed components, all unused services shall be disabled. The systems shall be hardened to the greatest extent possible without impacting clinical performance or utility. |
| 12 | All DICOM and HL7 traffic shall utilize resilient links that shall auto-restart with message/data failure/rejection/time-out and the system shall include a notification mechanism to the contractor and NTP support when failure is detected. |
| 13 | System shall incorporate a GUI tool (“dashboard”) for system administrators that at a minimum provides notification and visibility into all transmission and link failures. |
| 14 | System shall be deployed with Federal Information Processing Standards (FIPS) 140-2 compliant encryption of sensitive data at rest. |
| 15 | Where regional image ingest clusters are deployed, transfer between all NextGen PACS servers shall utilize Transport Layer Security (TLS) 1.2 or its successor. |
| 16 | HL7 interfaces shall support TLS 1.2 or its successor for connection to VA Data Access Services (DAS) (VA's centralized HL7 broker and gateway) and Cerner OpenLink. The system shall support HL7 ADT, ORM and ORU messages from all VA EMRs. |
| 17 | System shall be designed to optimally utilize bandwidth across the Wide Area Network (WAN) and to/from the cloud-based components. |
| 18 | All cloud-based components shall be hosted in VA Enterprise Cloud (VAEC). |
| 19 | System shall include an integrated contingency report server with fax or secure e-mail capabilities to allow for report distribution in instances where an HL7 interface issue prevents automated transmission. |
| 20 | At a minimum, the PACS shall log transactions in an audit trail at the following time points: user logon/logoff, receipt of images by PACS, each instance of a study being opened and who viewed and closed that study, on which workstation it was viewed (including if it was opened from the EMR), start of reporting, signature of report, successful upload of report, deletion of study and/or report, and any change to demographic or study information. Logs shall be maintained while the study is on the system. If a study is deleted and subsequently repulled, the original audit trail shall be reinstated. |
| 21 | The audit trail shall be kept for no less than three years and all PACS messages shall be synced with an internal VA time server. |
| 22 | Under administrative privileges, the system shall be able to support deletion of patient studies and images with an audit trail for all actions. |
| 23 | Transmission of any data outside of the VA network shall be via a VA approved VPN solution and is allowed only with FIPS 140-2 compliant encryption. Sensitive patient information shall not be stored outside of VA organizational control for purposes other than for short term troubleshooting purposes. After the requirement for the data has been satisfied, the data shall be securely erased. |
| 24 | Workstations and servers shall run anti-virus software and accept automated patching. |
| 25 | Non-diagnostic workstations for Tech and PACS Admin access shall utilize the standard VA baseline PC image and shall operate with the full suite of VA security controls. All applications, web-apps and associated components required for non-diagnostic support, workflow, management, administration, and operation shall be required to be fully functional on a VA baseline image PC. |
| 26 | Web-based applications for diagnostic and non-diagnostic workstations shall be fully functional with VA baseline versions of Edge and Chrome browsers and accept the VA browser security settings. |
| 27 | System shall operate without external Internet access per VA Medical Device Protection Program guidelines (exclusive of VPN connectivity). |
| 28 | Images shall not be permanently stored in non-volatile memory or hard disk on the reading workstations. |
| 29 | The PACS application database shall be dedicated solely to the NextGen PACS and comingling storage of VA PHI data with any non-federal data is not permitted. |
| SYSTEM ADMINISTRATION | |
| 30 | Erroneous, malformed, or non-conformant DICOM images or HL7 messages shall be automatically moved to an offline queue for resolution with a Graphical User Interface (GUI)-based notification/resolution tool. These messages shall not cause queues to back up or loop while other transactions await processing. |
| 31 | System shall incorporate tools for viewing and troubleshooting HL7 messages and provide PACS Administrators with access to those HL7 messages. PACS Administrators shall have access to the HL7 interface engine and native HL7 messages for troubleshooting purposes. |
| 32 | The system shall incorporate monitoring tools to track performance, storage usage, hardware health, system capacity, and uptime, and display critical parameters in real time. These monitoring tools shall be made available to VA PACS administrators. |
| 33 | The system shall provide a means for notifying both the VA PACS administrators and the contractor in the event of a failure. |
| 34 | System shall have a web-based administrative tool that enables PACS Administrators and Support to reconcile/correct studies sent with improper demographic or case number information. |
| 35 | When images are identified as belonging to the same study and are sent from a site to NTP, the system shall group them together for storage and display purposes. |
| 36 | The selection of a critical results diagnostic code by a Radiologist shall automatically initiate a support request via the communication tool and Support worklist to initiate a callback to the referring provider. |
| 37 | System shall provide a web-based administrative tool to split studies with duplicate Unique Identifiers (UIDs) and to split “combo studies” (head/chest CT, PET/CT, etc.) and assign a unique Study Instance UID (SIUID) to targeted images. It shall support aggregation of images into appropriate studies even if all images are not sent in the same association and it shall provide an admin tool to merge studies with distinct Study Instance UIDs. |
| 38 | Contractor shall support the storage/archival of all Required SOP Classes identified in Attachment 3 and identify which Optional SOP Classes in Attachment 3 are supported. |
| 39 | Contractor shall support the display of all Required SOP Classes identified in Attachment 3 and identify which Optional SOP Classes in Attachment 3 are supported. |
| 40 | DICOM servers shall be a promiscuous SSCP without a license restriction on the number of Application Entity (AE) Titles. |
| 41 | PACS shall support de-identification of reports and images and then export of those de-identified reports and images via DICOM and local media. |
| 42 | PACS shall support the import/ingest of scanned documents into both a DICOM Secondary Capture or DICOM Encapsulated PDF format. |
| INTEGRATION – PACS, HL7, EMR, MPI | |
| 43 | System shall interface with the VA’s Master Person Index, which is the primary system for assigning and maintaining unique person identifiers and provides enterprise-wide identity management. |
| 44 | System shall support multiple identifiers for each patient via internal Master Patient Index (MPI) functionality internal to the system. DICOM images, DICOM configurations for store, query/retrieve, and modality worklist, and HL7 messages shall incorporate MPI data to ensure that image and report interfaces uniquely identify patients across EMRs and PACS instances throughout VHA. |
| 45 | System shall normalize all VistA generated accession numbers to the following format: ###-MMDDYY-123 where ### is the 3-digit site code for the originating VistA instance. For accession numbers that require the ###- to be added to the beginning of the accession number for normalization within the PACS, the system shall strip the ###- out when sending the final report back to VistA. Accession numbers within the images, reports and orders shall all be normalized to this consistent format. |
| 46 | System shall support individual VistA upgrades from 2.3 to 2.4 and normalize the accession number, whether the 3-digit site code arrives prepended or not. |
| 47 | System shall normalize all studies and reports that utilize SSN as the primary identifier to the dashed format 000-00-0000. |
| 48 | For VistA sites, the HL7 interface shall support inbound ORMs and ORUs and NTP shall generate outbound ORUs and a VA specific message, VAQ, which sends a formatted HL7 message to release a case for local dictation. For Cerner sites, the HL7 interface shall support the addition of A08 and A34 ADT messages. |
| 49 | For sites that utilize Cerner as their EMR, the system shall be able to uniquely identify the patient via both the EDIPI and SSN and shall be able to utilize the appropriate identifier to issue a Q/R to a PACS that uses Cerner and simultaneously to one that uses VistA, e.g. patient in Spokane has a STAT x-ray and the site is using EDIPI as their primary identifier. That same patient has studies and reports in Bay Pines and within their PACS, the patient is identified via SSN. The NextGen PACS application shall utilize an MPI such that a query from an end user on the PACS shall correctly utilize the appropriate patient ID parameters in the query to successfully execute the Q/R to either location. That patient shall appear as a single instance within the NTP PACS and reports shall be issued to the originating site utilizing the site’s native patient ID parameters. Note that SSN format within VA PACS varies between dashed and no dash formats. |
| 50 | Contractor shall provide a fully operational test instance of PACS with all components. This shall be used for Cerner interface testing, application upgrade testing and potentially as a backup in case of either catastrophic failure and/or serious cybersecurity events. The system shall be capable of simulating at least 10% load of current production. |
| 51 | Contractor shall provide PACS database access to NTP's analytics application, Foundations, such that data can be extracted from PACS to Foundations. Additionally, PACS shall provide workflow status messages to Foundations via HL7 messages for tracking and analytics report creation. Sample workflow status messages include but are not limited to, image receipt, QA approved to dictate, study opened, report started, final report signed, etc. |
| PACS VIEWER | |
| 52 | The PACS viewer shall be a zero-footprint viewer or an application that auto-updates/auto-upgrades without the need for elevated privileges on the workstation (i.e. admin credentials) |
| 53 | The system shall be designed to accommodate 4 different categories/priorities: CRIT, STAT, ASAP, and Routine, with distinct turn-around times (TATs) for each level. The worklist shall display the time remaining before expiration of TAT for each unread exam. (PWS 5.2.1.13 and Attachment 2 NTP Workflow Detail) |
| 54 | PACS diagnostic viewer and associated voice recognition window shall fully launch and be ready for review/dictation within 3 seconds after study selection from the worklist or activation of the Next Study function. This shall include full fidelity display of current exam and 1 prior across all modalities based on 2x3 hanging protocol (HP) for cross sectional exams and 1x HP for DX exams. Performance target shall be met for users working within a VA site and home users working via VPN at 10 Mb/s minimum throughput. |
| 55 | Workstation shall have system level and user-defined hanging protocols based as a minimum on modality, series description, view, body part, with ability to quickly re-hang studies to a different layout as desired. For axial modalities, series in the same plane may be linked and scrolled in synchronization, even if the distance between slices differs or if the slices are of different thickness. Diameters shall be measured in metric dimensions for all modalities that have the pixel size available in the header, and it shall be possible to perform calibration for modalities that lack the pixel size. |
| 56 | Viewer shall support on the fly 3D reformatting including Maximum Intensity Projection (MIP) and Multiplanar Reformatting (MPR). |
| 57 | System shall have a scout and 3D localizer function. Via the mouse, users shall be able to drag the scout line to the desired location and the display shall move to that slice. Reference lines shall display and scroll in all planes. |
| 58 | Viewer shall provide support for teaching cases with deidentification of patient information. |
| 59 | Viewer shall support automated auto-linking/registration of multi-slice images across series among current and prior exams and shall include a semi-automated spine labeling tool. |
| 60 | The Radiologist viewing client shall run on VA-provided hardware with Windows 10 LTSC or Windows 10 Enterprise operating system or Windows 11. Workstations shall support VA approved anti-virus software (currently McAfee or Windows Defender but may change with subsequent VA-wide AV award). AV shall be deployed with contractor provided file or folder exclusions. PACS workstations shall permit automated Windows patching. |
| 61 | End user applications shall be made compatible with any new Windows major versions within 24 months of its commercial release. |
| 62 | PACS application and associated viewer shall be a cloud-native design with dynamic streaming as a fundamental design feature. The PACS viewer shall be fast, intuitive, stable, easy to use, and designed to optimize productivity and quality and reduce repetitive motion injuries. |
| 63 | Diagnostic viewer shall be optimized for WAN use with full fidelity streaming with a default of lossless compression. Image streaming shall be through encrypted traffic, ideally utilizing a fixed TCP port greater than 1023 if possible (use of higher ports decreases system vulnerability and provides an opportunity for more effective use of QoS). |
| 64 | Diagnostic viewer shall be designed as a cloud-native WAN-enabled streaming application with a minimum required bandwidth no greater than 10 Mb/s with WAN/VPN latency of 80 ms or less. WAN optimization is also required for Digital Imaging and Communications in Medicine (DICOM) traffic from local PACS or edge server to the NextGen PACS. Optimal WAN performance for all components of the NextGen PACS will be critical for the success of the overall project. |
| 65 | Data cached/stored on the workstation shall be deleted from the system at the close of the study or application. |
| 66 | System shall include a real-time productivity tracking tool visible for each respective Radiologist within their PACS worklist. The tool shall be configurable to display daily wRVU or adjusted wRVU (NTP specific wRVU values per CPT code and LOINC codes for Cerner sites). |
| 67 | Viewer shall include an integrated collaboration tool for communication within the PACS between Radiologists and/or support staff with the ability to send embedded study links in the messages. Collaboration tool shall have the ability to broadcast messages to online users with individual and group responses and shall incorporate logging as well. |
| 68 | The system shall provide the ability for Radiologists to jointly confer on a study in real time while they view it. |
| 69 | The system shall provide visual cues on the worklist that indicate a study is approaching expiration of the assigned turn-around-time within the 4 priorities (CRIT, STAT, ASAP, and Routine). |
| 70 | The system shall provide a separate visual cue on the worklist to indicate a study is overdue from the assigned turn-around-time within the 4 priorities (CRIT, STAT, ASAP, and Routine). |
| 71 | The Radiologist shall be notified if another user is viewing the same exam on another workstation and shall be prevented from creating a duplicate report. |
| 72 | The system shall immediately notify the Radiologist if a local report for a study they are viewing has been received. This can occur when a site disregards the stub message or initiates dictation before the NTP stub report is filed. The system shall also immediately notify the Radiologist if additional images are received on a case they are currently dictating. |
| 73 | Worklist shall allow manual reassignment of studies to another radiologist, indicate what studies have been reported, and whether the report has uploaded to the EMR successfully. Manual reassignments shall be a logged event as this process needs to be highly monitored. |
| 74 | Patient history and reason for study shall be mapped from the HL7 message and shall be available for review within the worklist. |
| 75 | For compressed images, compression ratio shall be displayed for each image. For images that have been lossy compressed in the past, the “compression” flag available in the header shall be indicated to the user. |
| 76 | System shall be able to support Values of Interest Look Up Table (VOI LUT) and be able to selectively apply all the LUTs sent with the study. |
| 77 | System shall be capable of creating and storing multiple presentation states and key images/series. Key images and images with annotations shall be automatically written back to the originating PACS once the report is finalized. |
| 78 | System shall be capable of accepting and displaying a site created study with multiple presentation states. |
| 79 | User annotations shall be stored and retrievable for future viewing. |
| 80 | System shall have viewer-based query/retrieve. |
| 81 | Text overlays shall be configurable as a system-wide setting based on modality. The system administrator and/or user shall be able to change the overlay based on any DICOM tag. |
| 82 | System shall support flexible image placement of any image, and any series on any monitor via drag and drop or simple mouse clicks. |
| 83 | The system shall, either by default or via system configuration, limit the number of active dictation windows to a single exam. Multiple exams can be open simultaneously as outlined above, but only 1 report can be in an active dictation state. |
| 84 | The viewer shall include an integrated PET/CT fusion tool. |
| 85 | The viewer shall include the full suite of mammography viewing and hanging protocol tools for both traditional full field digital mammography and tomosynthesis studies and be approved for diagnostic interpretation of these exams. |
| 86 | The viewer shall implement all common combinations of pixel size, photometric interpretations, overlays, scaling, negative/positive pixels, etc. in addition to the pixel pipeline instructions as directed by Presentation States as defined in the Consistent Presentation for Images (CPI) IHE. |
| VOICE RECOGNITION (VR) | |
| 87 | VR system shall be designed with 99.99% uptime goal. It shall operate in a high availability configuration with automated failover. |
| 88 | VR system shall support VA configured anti-virus and automated OS patching. System shall be capable of being patched with server reboots without going offline. It shall be continuously operational while successive servers within the cluster are patched or updated and rebooted. This shall be managed by the NextGen PACS contractor or their subcontractor as part of ongoing maintenance to include vulnerability remediation. |
| 89 | VR system shall have a seamless API integration with the PACS viewer and worklist to launch the VR report in patient context. |
| 90 | VR system shall include enterprise-based VR profiles that allow users to rotate workstations and/or reading centers with no user reconfiguration required. |
| 91 | VR reporting system shall be able to support connection to all VA facilities, each with their own HL7 interface. VR system shall also be able to support an interface to Cerner OpenLink as sites transition between VistA and Cerner. |
| 92 | VR system shall be able to handle parent/descendent exams and be able to copy/paste reports into unlinked/associated accession numbers. |
| 93 | VR system shall support VA-wide, site specific and user specific templates. |
| 94 | VR system shall support VA defined diagnostic codes and the issuance of multiple diagnostic codes. Note for VistA sites, NTP utilizes a fixed set of diagnostic codes (DX = 1000 – 1003 for primary codes and 1200 series and 1300 series secondary codes). For Cerner sites, the VR/PACS shall translate the NTP selected DX codes into 1 of 3 normalcy indicators – Normal, Abnormal or Critical. VA Sites can use the national DX codes or may have their own site-specific code set. |
| 95 | VR system shall prepopulate measurements, contrast, radiation dose and AI information using a DICOM Structured Report (SR) as input. This shall be automated and occur in the background. |
| 96 | The name of the reading Radiologist, as well as the date and time the interpretation was completed shall be automatically included at the end of the Impression along with the NTP address and contact number. For NTP reports, the Primary Interpreting Staff value within the HL7 message shall be transmitted as “Radiology, Outside Service” and the DX code shall be displayed within the text of the report. For VISNs using the NextGen VR, the address and contact number shall be configured specific to individual sites. |
| 97 | The system shall electronically upload preliminary stub reports upon study receipt and final signed reports to the originating hospital location. The system shall support multiple addendums for a period of up to 6 months. |
| 98 | The system shall support the removal of a NTP prelim report from VistA or Cerner via transmission of a custom VAQ message. |
| 99 | The dictation system shall have an inventory of prebuilt templates and shall be capable of building macros. Templates shall be automatically structured and prepopulated with procedure and demographic data based on HL7 data. |
| 100 | VR system shall be able to copy a report onto an accession number for which there are no images in PACS, e.g., site does not link abdomen and pelvis accession numbers and sends the complete study under 1 accession number. NTP shall be able to copy report over to the unlinked accession number. |
| 101 | VR system shall be able to utilize a range of input devices from handheld VR specific microphones to USB and Bluetooth microphones. |
| ARTIFICIAL INTELLIGENCE | |
| 102 | System shall include artificial Intelligence (AI) functionality with no less than Intracranial Hemorrhage (ICH) identification, large vessel occlusion (LVO), breast density and breast cancer modules. All AI modules used in production must be FDA approved. |
| 103 | System shall automatically route candidate cases to the various AI algorithms based on configurable parameters using HL7 and DICOM values. All routing shall be optimized to reduce transfer and analysis timelines. |
| 104 | Positive AI findings shall trigger a change to a higher priority status. Negative findings shall not decrement the submitted priority level. |
| 105 | Workflow and analysis for ICH AI processing shall be no more than 10 minutes from image ingest at the PACS server to completed analysis with priority status change for a positive finding and write back/storage of key images. |
| 106 | AI processing shall generate a structured report to VR system and write back to the PACS with a secondary capture series identifying the finding (positive, negative, unable to process) and will identify the specific slice that triggered the finding. |
| WORKFLOW TOOLS – IMAGE QUALITY, CALLBACK, SUPPORT, PEER REVIEW & NTP SPECIFIC TOOLS | |
| 107 | The system shall include a closed-loop support request tool between Support and the Radiologists to facilitate assistance requests and critical results. The support tool shall provide a mechanism for Support to “claim” a request, so multiple individuals do not work on the same problem and the requestor knows who has the assignment. |
| 108 | System shall include an internal collaboration tool. User list shall default to online users within the logged in user’s organization (NTP, VISN X or site Y) but shall permit cross org communication via org drop down selection. |
| 109 | System shall interface with existing NTP STAT web portal (Foundations from Health Level) or contractor can provide a customer-facing web portal for Support interaction and case submission. STAT and Critical cases sent to NTP have 2 separate submission components: DICOM export of case to be read along with relevant priors and an accompanying web portal submission. The web portal submission is used by the Techs at the site to notify NTP that a case has been sent and it provides contact information if a callback is required, image count, exam notes, etc. The existing web portal sends PACS an HL7 message with the submitted information. That data shall be incorporated into PACS for pre-read QC and Radiologist viewing. |
| 110 | System shall immediately assign critical exams (stroke and intraoperative radiograph) to a qualified Radiologist once processed by Support and shall be treated as the highest priority. Once cleared to read, the assigned Radiologist shall receive an automated notification within their worklist or viewing window alerting them that they have a case that needs immediate interpretation. |
| 111 | The PACS shall provide a pre-read QC worklist for cases sent to NTP. The cases shall be automatically placed in a pending QC status with a distinct worklist for NTP PACS Assistants (Support). Support shall utilize this worklist to review unread cases for completeness and determine if relevant priors have been sent. The QC worklist shall include functionality such that cases that are opened by Support shall be “claimed” by the specific Support staff reviewing the case and once they mark the case ready to read, it shall be released for interpretation. |
| 112 | Upon receipt of a STAT or CRIT web portal request, the system shall automatically upgrade the priority of the case within PACS to the same status regardless of the HL7 ORM priority value. |
| 113 | The pre-read QC worklist shall display relevant HL7 exam information along with image thumbnails for each series transmitted. The worklist shall display the patient history/exam timeline, show available reports on PACS, available images/studies on PACS and shall provide an integrated tool to query various PACS in VA where the patient has images. |
| 114 | Upon receipt of a study to be interpreted, the PACS shall automatically issue a c-find to each PACS instance where there is an order or report on file. The c-find response shall be normalized to provide a consistent accession number and patient ID format across all sites and shall be utilized to update the pre-QC worklist with the image availability status in PACS across all instances where images for that patient reside (online or query-able). |
| 115 | Within the pre-read QC worklist for Support, it shall take no more than 3 mouse clicks to retrieve a relevant prior: click 1 – open case from Support worklist, click 2 – select patient history tab or window and review list of priors that are on PACS or have been identified via automated c-find to PACS where the patient has previous imaging, and click 3 – retrieve relevant prior(s). |
| 116 | PACS shall incorporate a post-assignment problem list to track cases that the Radiologists identify which need to be addressed by Support prior to sign off. Worklist shall function similar to the pre-read QC list where Support will claim the case and will address the issue until resolved. The post-assignment problem list shall also incorporate workflow for critical callbacks where the Radiologist is notifying Support that a critical callback is required. |
| 117 | System shall include a GUI tool that can implement site by site business rules (BRs) for automated study QR based on pre-programmed criteria (CPT code, study description, time of day, day of week, quantity, location, and priority). The BR tool shall allow NTP to set up rules to automatically query a set number of cases per day from the sites we support, e.g. 5 MRI MSK exams from site X M-F from 12 pm to 5 pm local time, and 50 DX M, W, F from 8 am to 5 pm. |
| 118 | For routine cases pulled via BRs, the system shall also query relevant prior exams from the host PACS. |
| 119 | Q/R shall be available via GUI tool embedded within the NTP Support QC workspace and shall also be available within the PACS viewer. |
| 120 | System shall provide PACS administrators with the ability to dynamically change DICOM Q/R targets as facilities change PACS contractors and/or servers, without a system downtime. |
| 121 | System shall include a GUI tool for DICOM export to any connected PACS. Tool shall permit PACS Administrators to configure and select destinations and shall provide status on transfer actions. |
| 122 | Integrated American College of Radiology (ACR) compliant peer review functionality with on demand and assigned workflows shall be provided. Peer review shall incorporate separate workflow and scoring methodologies for internal NTP peer reviews and peer reviews that NTP performs for VA customer facilities. Note the system shall include similar peer review capabilities for the VISN PACS, however the external review functionality is typically used by NTP. The specific scoring criteria that is used for each type of review (NTP internal versus VHA-site focused review) shall be specific for each org, e.g. NTP peer reviews will have RadPeer scoring as the displayed option while a review for site A would have met/not met criteria listed and site B review would display RadPeer. |
| ASSIGNMENT ENGINE & WORKLIST | |
| 123 | The system shall include an assignment engine (AE) that is fully integrated with the PACS worklist. The AE design shall be designed to minimize report turn-around time while maximizing subspecialty interpretations. |
| 124 | AE shall support no less than 12 distinct subspecialty designations for STAT and CRIT workflow and no less than 12 designations that are applicable for Routine and ASAP priority cases. |
| 125 | AE shall utilize a combination of CPT codes, LOINC codes (for Cerner sites), study descriptions, and priorities to identify the subspecialty group(s) for each case to be interpreted. |
| 126 | AE shall assign a fixed number of CRIT/STAT and ASAP/Routine cases to each logged in Radiologist. The system shall also support assignment of a fixed wRVU amount to each active Radiologist. |
| 127 | System shall have a default setting of “Auto Next” to automatically open the next case on the Radiologist’s worklist along with associated report template. Disabling Auto Next shall be an elevated system privilege. |
| 128 | System shall incorporate a “Skip” function that shall allow a Radiologist to move to the next case and temporarily bypass Auto Next. If Skip is invoked, it shall require a comment from the Radiologist and it shall be an auditable/logged event. |
| 129 | NTP and VISNs shall operate on unique instances of the AE so that NTP workflow shall not dictate subspecialty assignment for other VISNs who use the NextGen PACS. In other words, each Org, (NTP, VISN1, VISN2, site X) shall have their own worklist and AE setup and an administrative tool to manage AE configuration. |
| 130 | AE shall continually update system status in the background and within 1 second of report signoff, it shall have the next available case assigned to any Radiologist. |
| 131 | AE shall be configurable by PACS Administrators via GUI to change assignment parameters, subspecialty groups and subspecialty mapping. |
| 132 | Multipart exams such as CT chest plus abdomen/pelvis shall be managed as separate exams if sent to the PACS with distinct image sets and shall be evaluated by the AE accordingly. |
| 133 | System shall support the use of a fixed set of mandatory worklists or worklist filters that shall be the default configuration within the system. Example worklists may include: CRIT Exams, CRIT and STAT, etc. |
| VISN PACS ARCHITECTURE AND DIFFERENTIATORS - SPECIFIC TO PHASE 2 (VISN PACS) | |
| 134 | For VISN PACS deployments, the system shall provide a local image cache housing a minimum of 2 years’ worth of images and shall be expanded up to 5 years if required to provide LAN level viewing performance for simultaneous review of current and prior exams. |
| 135 | The system shall support intra-VISN interpretation for VISNs that utilize the NextGen PACS. |
| 136 | VISN PACS shall operate as a distinct organization within the overall PACS and roles, security, etc. and shall be limited to the specific organization that the user is assigned to. Facilities within the same VISN may elect to have site-specific workflows that are unique to their site. The PACS shall support this level of differentiation. |
| 137 | Each site within the VISN PACS may elect to utilize distinct diagnostic codes and VR templates. The PACS and voice recognition systems shall support site level customization. |
| 138 | System and application administrative rights shall be configurable for least privileges based on site, VISN or enterprise level, i.e. a local PACS Admin at a site that uses the NextGen PACS shall not have access to administrative functions for their VISN configurations or the NTP configuration, VISN PACS Admins will not have access to NTP/system level privileges. |
| 139 | Application authentication shall be via PIV card or single sign-on through Windows authentication and users shall be permitted access to multiple Orgs as required. For example, a VA Radiologist working at a site that utilizes the NextGen PACS also works for NTP as a Fee Basis Radiologist. At sign in, they shall be presented the option for which Org they will log into, and their Org-specific configuration shall be loaded, e.g., their VR template, diagnostic codes configured for their site (primary VA hospital or NTP) shall be available in their user interface and the configurations which are specific to the Org that they are not logged into shall not be available. |
| 140 | Contractor shall provide a fully operational test instance of PACS with all components for each VISN that utilizes NextGen PACS as their internal PACS solution. This shall be used for interface testing, application upgrade testing and potentially as a backup in case of either catastrophic failure and/or serious cybersecurity events. Each VISN test PACS shall incorporate the full functionality of their production system but shall be scaled to 10% of the VISN’s annual capacity. |
| VISN PACS DICOM MODALITY WORKLIST - SPECIFIC TO PHASE 2 (VISN PACS) | |
| 141 | VISN PACS deployments shall provide a DICOM modality worklist (DMWL) for the imaging modalities at non-Cerner sites. At Cerner sites, Cerner shall be the DMWL provider for PACS. |
| 142 | The DMWL shall support DICOM MWL FIND as a Service Class Provider (SCP) for DICOM SOP 1.2.840.10008.5.1.4.31. |
| 143 | The DMWL shall be able to filter responses to the modality based on various DICOM tags including the following: date range, modality type, modality calling application entity (AE Title) and Station name, Accession Number, Patient Name and Patient ID. Based on the calling AET, the DMWL SCP shall be able to provide only MWL responses for that site. The DMWL SCP shall be able to filter responses using specific, configurable, status codes events. |
| 144 | The PACS Administrators shall be provided access to create and/or modify the DMWL configuration, filtering and HL7 to DICOM mapping as site needs change and/or modalities are upgraded or replaced. |
image1.png
File details come from the government source that posted it. Updated .