S02 ATTACHMENT D.9 - SUMMARY_OF_PACS_HL7_FOR_SCHEDULED_WORKFLOW.pdf

Summary of PACS HL7 Testing for Scheduled Workflow

PACS will be expected to process information correctly and appropriately in the order, patient update and report situations described below. Information, or the absence of information, should be visible to the user of the PACS display.

Each test involves the receipt of one or more HL7 messages by PACS, the sending of one or more acknowledgments to VistA, and the capture of one or more screen shots showing the effect on the PACS of the messages received. A successful test is one in which the PACS fulfills the requirements listed in the “Dynamic Definition” section of the relevant profile in the document Profiles for HL7 Messages from VistA to Commercial PACS. PACS software engineers and analysts are advised to be familiar both with these dynamic requirements and with the message processing rules and acknowledgment message definitions given in the HL7 Standard, Version 2.4, Chapter 2, Sections 2.13 and 2.14, which will also be validated during testing.

Rejection and error conditions will be pre-tested to validate the operation of the PACS messaging interface when messages containing exception conditions are received.

Testing shall encompass specific requirements enumerated in the Dynamic Definition sections of the Profiles document (Sections 1.3, 2.3, 3.3, and 4.3), including the following.

• Order and patient update scenarios

• Acceptances: PACS will properly file information and statuses for each of the following conditions.

• New order

• New order followed by order-examined message

• New order for pregnant patient

• New order for sensitive patient

• New orders each succeeded by one of the following:

o Demographic update o Transfer and cancellation (for PACS that display patient location information) o Discharge and cancellation (for PACS that display patient location information)

• Cancellation of order

• New study for existing case

• Primary patient ID (ICN) merge with ID not previously used

• Primary patient ID (ICN) merge with ID previously used

• Secondary patient ID (SSN) change

• Date of birth change

• Administrative sex change

• Rejection and error conditions will be tested at the same time.

• Report scenarios

• Acceptances: PACS will properly file information and statuses for each of the following conditions.

• New order followed by report (no other report related to this order on file)

• New order followed by report (previous report on file)

• New order followed by report (subsequent report on file)

• Report sent without corresponding order having been sent

• Rejection and error conditions will be tested at the same time.

July 2007 VistA Imaging HSD&D 1 of 2

Validation Testing Requirements and Results Reporting

• To eliminate any risk to actual VA patient records, it is a requirement that both the VA testing system that generates the messages and the vendor system that receives the messages reside outside the VA firewall, so that there is no possible access to Patient Health Identifiers (PHI).

• Until and unless otherwise announced by VA, a cycle of HL7 vendor testing (which will exercise all the functions listed in the “Test Summary” section above) may begin at any time, but testing must be scheduled in advance with the VistA Imaging HL7 team

• During a cycle of testing, testing days need not be consecutive calendar days.

However, no more than 14 calendar days may be skipped between testing days. If more than 14 calendar days elapse after a testing day without a testing cycle having been completed, results from the current testing cycle will be set aside. Subsequent testing must begin in a new testing cycle.

• Testing will begin by having an assigned VA tester send a series of exception messages to PACS. These messages will include such items as errant HL7 message types or version numbers, demographic mismatches on order update messages, etc.

These exceptions must be processed correctly before proceeding with testing the effects of received messages on the behavior of the application.

• The VA tester shall then work with a vendor tester to perform each test of the effects of received messages on specific behaviors of the application. During each test, the VA system shall send one or more messages and the vendor tester shall report system behavior upon receipt of each set of messages sent by VA.

• After each message is received and effects are reported on verbally by the vendor tester, the VA tester shall note any gaps or variances in receiver behavior. If no failure is detected, the VA tester shall inform the vendor tester of the test number and the vendor system database records to be provided as evidence of successful test completion. Vendor system data shall be provided in the form of screen shots of the vendor’s system showing the data provided by VA.

• The VA tester shall report of variances in expected receiver behavior to the vendor tester.

• Subject to VA resource constraints, there is no limit on the number of testing cycles that may be executed between VA and any vendor. In order to allow fair access to all vendors, a subsequent cycle of vendor testing may begin as late as 14 calendar days after the conclusion of a previous cycle of testing, depending on the VA’s testing schedule.

July 2007 VistA Imaging HSD&D 2 of 2