How To Integrate With the VA VistA PACS

Introduction 🔗

We had the opportunity to help a client get their device approved as a vendor for the VA’s VistA system. We were able to see first hand the pitfalls of the process and what steps can be taken to navigate them effectively. This validation can often become a major bottleneck in medical device sales.

In this article we’ll walk you through the process of becoming an approved VA vendor for the VistA PACS system. We’ll also give examples of some of the specific gotchas that we came across in our review process. These include inconsistencies in the VA requirements, quirks in the validation process, and areas where pushing back can make your process smoother.

Finally we’ll cover our strategy for obtaining validation, which we’ve developed to complete this process with minimal delays and setbacks.

What Is VisTa? 🔗

The Veterans Health Information System Technology Architecture (VistA) Imaging system is the PACS (Picture Archiving and Communication System) used by the US Department of Veterans Affairs in their hospitals and clinics.

The VA is the largest hospital network in the country and therefore represents a large possible customer base for medical devices. Having an approved device opens the door to numerous sales possibilities.

VistA validation process 🔗

1. Create a DICOM conformance Statement 🔗

A DICOM Conformance Statement is a detailed document provided by manufacturers of DICOM-compliant software and medical imaging devices, such as scanners and PACS. This document outlines how a device or software application implements the DICOM standard, detailing the supported features, functionalities, and communication protocols. It serves as a reference for ensuring interoperability between different systems.

Your conformance statement should clearly describe these key elements:

1. DICOM Service Classes and SOP (Service-Object Pair) Classes: Outline which DICOM service classes (e.g., Storage, Query/Retrieve) are supported by your device and include a detailed description of how these services are implemented.
2. Supported Transfer Syntaxes: Specify the transfer syntaxes (e.g., JPEG, JPEG2000) your device supports for encoding and decoding DICOM images.
3. Communication Protocols and Configurations: Describe the supported communication protocols (e.g., TCP/IP) and configuration parameters (e.g., AE Title, Port Numbers).
4. Supported Attributes and Information Entities: Define the DICOM attributes and information entities that your device supports, such as Patient, Study, and Series level attributes.

• Tip: We recommend using the current NEMA standard

  

  • Make sure you are using the current template: DICOM Conformance Statement Template (Normative)
• Gotcha 1: There are some features for the conformance statement not present in the NEMA standard that are required by the VA
  • Example: In our review, we had to add the Image Storage Attributes table from the VA’s own documentation. This table was not present in the NEMA standard but was a prerequisite for completing the VA’s validation.
  • Tip: Before submitting your conformance statement, cross-check with the VA’s documentation to ensure that all VA-specific requirements are addressed. Missing these entries could lead to requests for additional information and delays in your review.
• Gotcha 2: Be precise in your language
  • Example: When drafting our conformance statement, we referred to a C-FIND operation as “query retrieval” without specifying that it was for a Modality Worklist. This led to confusion for our reviewer, who assumed that our device was acting as a workstation rather than a modality. This mistake almost caused us to be categorized into a different, and much longer, review process.
  • Tip: Use standardized terms that are explicitly defined in the DICOM standard. Avoid generic terms or shorthand that could be misinterpreted, as this could result in significant miscommunication with your reviewer and delay your approval.

2. Fill out the VistA compliance checklist 🔗

The VistA compliance checklist is a comprehensive document that outlines the features, actions, and behaviors expected from a DICOM-compliant device or software application when interfacing with the Veterans Health Information Systems and Technology Architecture (VistA) system. This checklist is used by the VA to verify that your product meets the required interoperability and performance standards necessary to operate within the VistA environment.

The checklist is divided into various sections that correspond to different DICOM SOP (Service-Object Pair) classes and service types. Filling out this document accurately provides the VA with a detailed view of which functionalities need to be tested during the compliance review. This step sets up the review process for your live session, so accurately completing this form will improve your review process tremendously, and prevent any unforeseen issues during the call.

Common Challenges for this Step

• Gotcha 1: Be mindful of communication expectations:
  • Example: During our review, we submitted a well-documented checklist, but we didn’t realize that some key information, such as the Vendor Name, Modality Type, Product Name, and Software Version, was also required to be included in the body of every email communication. This oversight resulted in a significant delay in the review process. The reviewers were waiting for us to provide this information directly in the email, while we were under the impression that they were already reviewing the checklist. This misunderstanding set us back by three weeks.
  • Tip: Confirm with your reviewer what information needs to be included in every correspondence, and consider creating a standardized email template that includes these details. This will minimize the chances of communication lapses and expedite the review process.

• Gotcha 2: The required features can be ambiguous: The checklist may list certain features as mandatory, but these requirements are not always enforced in practice

  • Example: During our review, we noticed that the Modality Performed Procedure Step (MPPS) was marked as mandatory in the compliance checklist. Since our device’s use case did not involve MPPS, we postponed its implementation and sought clarification from our reviewer. To our relief, we were informed that MPPS was not actually required for our particular validation scenario.
  • Tip: If you encounter a feature listed as mandatory that seems unnecessary for your use case, reach out to your reviewer before investing time in implementation. There may be flexibility based on the context of your product and its intended usage within the VistA system.

3. Submit validation request 🔗

The validation request is your official submission to initiate the DICOM validation and testing process with the VA. This step marks the beginning of the review and testing phase, where the VA will evaluate your device’s conformance to DICOM standards and VistA requirements. The process typically involves a series of email communications and testing sessions, all of which are coordinated through the validation request.

• Gotcha 1: Only the Manufacturer Can Perform the Validation:
  • Example: During our first submission, we encountered an unexpected delay when the reviewer replied with the message: “Only manufacturer can perform validation.” This happened because we, as third-party vendors, had submitted the request on behalf of our client, who was the manufacturer. Although we included all the necessary documentation and information, the VA required that the manufacturer be directly involved and listed in every communication thread.
  • Tip: Ensure that the device manufacturer, be it you or your client, is CC’d on every email and actively participates in all validation-related calls and discussions. When we resubmitted our request with the manufacturer’s email CC’d, we immediately received a confirmation of our request, which allowed us to proceed to the next steps without further issues. Keeping the manufacturer engaged in all communications is crucial for avoiding unnecessary delays and ensuring compliance with VA guidelines.

4. Conduct Offline Testing 🔗

Offline testing is a useful step in the validation process that provides an opportunity to test your device's DICOM communication and data handling capabilities in a controlled environment before moving to live testing. It allows you to troubleshoot potential connectivity and data exchange issues without requiring immediate feedback or oversight from the VA. This step is invaluable for identifying and resolving initial problems that might otherwise cause delays or complications during the formal validation phase.

What to Expect During Offline Testing 🔗

Once your validation request is accepted, the VA can temporarily grant your system access to their network for a 24-hour period. During this time, you may perform various DICOM operations to ensure that your device is communicating correctly with the VA’s systems. This offline access is typically used to validate basic connectivity and initial data exchange, giving you a chance to refine your system setup and address any configuration issues.

• Connection Testing: Use this time to send and verify DICOM commands like C-ECHO to confirm that your device can establish a connection with the VA system. This operation is essentially a "ping" test for DICOM devices, allowing you to ensure that your IP address is correctly configured and can reach the VA’s DICOM server.
• Data Querying: You can also perform C-FIND requests to query available data and confirm that your device can correctly parse and handle responses from the VA’s system. For example, if your device needs to interact with modality worklists, use the offline access period to test your ability to query and receive worklist information.

Note: The VA will not offer support during this offline testing period. This means that if you encounter issues with more complex operations, such as C-STORE or C-MOVE, you’ll need to diagnose and resolve them independently. Offline testing is primarily intended for verifying basic connectivity and query operations, and support for more complex data exchange commands is not typically available at this stage.

Key Considerations and Best Practices 🔗

1. Request Offline Testing Proactively:
   Many vendors are unaware that they can request offline testing ahead of the formal validation process. Information about offline testing is often not prominently featured in the VA’s documentation, and the availability of this resource can vary based on the specific reviewer and validation case. However, proactively asking for offline testing access can save significant time by allowing you to identify and resolve issues early on.
   • Tip: If your reviewer does not mention offline testing during the initial discussions, bring it up and request access. Emphasize that having this access would enable you to validate connectivity and basic communication protocols ahead of time, which can streamline the subsequent phases of validation.
2. Use the Full 24-Hour Access Window:
   Make the most of the 24-hour access window by preparing a comprehensive set of tests and scenarios to run during this time. Plan to test not only basic connectivity but also various DICOM commands and data exchange operations that are critical to your device’s functionality. Having a well-defined testing plan can help you quickly identify issues and gather the information needed to troubleshoot effectively.
3. Log and Document All Findings:
   Keep detailed logs of all commands sent and responses received during the offline testing period. This documentation will be invaluable if you need to report any issues or request clarification from the VA reviewers during the formal validation. Additionally, these logs can serve as a reference for future testing phases or as evidence of your system’s initial connectivity and data handling capabilities.
   • Tip: Set up automated logging for all DICOM operations performed during the offline testing. This will help ensure that no detail is missed and can make it easier to analyze issues after the testing window has closed.

5. Go through validation session (1-6 hour video call) 🔗

The live validation session is a most complex step in the approval process, where your device or application will be tested in real time by the VA reviewers. The session typically involves a series of tasks and test scenarios that demonstrate your device’s ability to interact correctly with the VA’s DICOM infrastructure. These sessions can last anywhere from 1 to 6 hours, depending on the complexity of the system being tested and the number of issues encountered during the session.

What to Expect During the Validation Session 🔗

The format of the call and the tests performed will vary depending on the device being validated and its intended use within the VA system. During our validation session, we were required to complete a series of Modality Worklist Queries using provided Accession Numbers and to send a device-generated image with specific criteria based on one of these Accession Numbers.

• Modality Worklist Query: This involves sending a C-FIND request to query the Modality Worklist for a set of criteria provided by the reviewers, such as Accession Numbers. This step tests your device’s ability to handle query retrieval and display accurate worklist entries.
• Data Transmission: After a successful worklist query, you may be required to generate and send DICOM images based on the queried data using C-STORE requests. This ensures that your device can correctly format and send image data in compliance with the VA’s standards.
• Handling Failures: It is not uncommon to fail the first attempt at validation. For example, our device did not initially support querying by Accession Number because our users typically only filter patients using Procedure Date. This issue alone prevented us from passing the first validation attempt.

Key Considerations and Best Practices 🔗

1. Don’t End the Call Prematurely:
   Even if you fail a specific test or validation step during the session, it’s important to use the remaining time on the call to your advantage. Continue working with the VA’s PACS system and run as many tests as possible to identify and resolve additional issues. If your reviewer is willing, use the access time to troubleshoot problems in real time and perform additional testing. This proactive approach can help minimize the number of issues encountered in future validation sessions and reduce the overall time needed to achieve approval.
   • Example: After we were informed that we had failed due to our inability to query by Accession Number, we immediately ended the session, assuming no further testing could be done. In hindsight, it would have been much more beneficial to continue working through the call to test other features and troubleshoot additional issues. This would have saved us time and effort during subsequent testing attempts.
2. Leverage Detailed Logging:
   Detailed logging can be a lifesaver during the validation session. Having logs that capture all commands, responses, and errors in real time can provide invaluable insight into what exactly went wrong and why. This information can be used to make on-the-fly adjustments during the call or to quickly identify the root cause of issues after the session.
   • Tip: Set up automated logging for all DICOM operations and responses during the validation session. The more detailed the logs, the easier it will be to diagnose and resolve issues on the spot. We were able to make small adjustments to our DICOM files based on the logs, which allowed us to pass the second attempt rather than having to wait for a third session.
3. Know Your Conformance Statement Inside and Out:
   During the call, you will be asked to reference specific sections, tables, and information from your DICOM Conformance Statement. Being able to quickly and accurately point to these details will demonstrate your understanding of your system’s capabilities and the thoroughness of your documentation. The process will move much more smoothly if you are well-versed in the content of your conformance statement.
4. Push Back When Necessary:
   Use the validation session to push back and clarify any discrepancies between the VistA documentation and what the reviewer considers mandatory. Not all requirements listed in the documentation are strictly enforced during validation, and there are often differences in how individual reviewers interpret these requirements. Understanding what is truly necessary for passing and what is merely a recommendation can help you navigate the session more effectively.
   • Tip: If a reviewer insists on implementing a feature that seems unnecessary or is not explicitly required, ask for clarification and try to understand the reasoning behind it. In some cases, the reviewer may agree to proceed without the feature or offer alternative solutions.

6. Confirm Device Name and Version 🔗

After successfully completing the validation call, the final step is to confirm your device name and version number with your reviewer. This is a straightforward process, but it’s important to ensure that all information matches what was used during the validation. Your reviewer will prompt you to send an email with these details, which will then be used to officially add your device to the VA’s list of approved vendors.

7. Get Listed on the VA List of Vendors 🔗

After submitting your device name and version following a successful validation call, your next step is to await your listing on the VA’s approved vendor list.

Update Schedule: The VA’s list of approved vendors is typically updated once a month. Therefore, even after your validation is complete, there may be a delay before your device is officially recognized on the list. It's essential to keep this timeline in mind, especially if you're planning product launches or marketing strategies that rely on your vendor status.

Recommended Strategy 🔗

Based on our experiences navigating the validation process, we recommend a strategic approach that balances thoroughness with efficiency. The following procedure has proven effective in achieving a successful outcome while minimizing delays:

1. Submit a Validation Request with the Bare Minimum Begin by submitting a validation request that includes only the essential components necessary to demonstrate compliance. While addressing every requirement has less risk, this can significantly prolong the preparation time. Instead, focus on the core functionalities and features that you believe are crucial for passing the initial assessment. This risk-taking strategy allows you to engage with the validation process sooner, providing opportunities to learn and adapt based on real feedback.
2. Request Offline Testing Once your request is accepted, immediately ask for offline testing. Utilize the 24-hour access period to thoroughly test your device’s connection and functionalities, especially through commands like c-echo and c-find. This is a critical opportunity to identify and rectify initial issues before the live testing phase. Since the VA will not provide support during this time, be prepared to troubleshoot independently. Take detailed notes on your findings, as this information will be invaluable for addressing any potential shortcomings before subsequent testing.
3. Engage in Live Testing with an Open Mind When you enter the live testing phase, adopt a mindset that anticipates challenges. It’s common to encounter failures during this stage, particularly if your device's workflow does not align perfectly with the VA's requirements. Rather than viewing failure as a setback, consider it an opportunity for learning. During the testing session, pay close attention to the specific reasons for any failures and gather as much feedback as possible. This information will guide your adjustments and improve your chances of success in future attempts.
4. Submit a Second Validation Request with Corrections After incorporating the insights gained from your live testing experience, submit a revised validation request that addresses the identified issues. Continuous communication with your reviewer throughout this process can also facilitate a smoother validation experience.

By following this strategy, you not only streamline your approach to validation but also foster a responsive, adaptive process that enhances your device’s compliance with VA requirements. This method minimizes wasted effort and maximizes learning opportunities, ultimately leading to a more efficient pathway to success.

Conclusion 🔗

Navigating the VA validation process can be challenging, but it’s essential for accessing the vast healthcare network managed by the Department of Veterans Affairs. While VA validation ensures that your device meets the VA’s specific criteria, it doesn’t necessarily guarantee that the device will work seamlessly with all real-world PACS systems.

The requirements for VA validation and those for full PACS integration overlap but are not identical. There are elements you must implement for VA compliance that may not be relevant for other PACS systems, and vice-versa. Successfully passing the VA validation is a significant milestone, but additional testing and fine-tuning will likely be needed to ensure compatibility across a broader range of PACS environments.

By focusing on the intersection of these requirements, and understanding where they diverge, you can better prepare your device for both validation and real-world use—ultimately making it more robust, reliable, and marketable across various medical settings.