Verify survey response was processed

This step is very subtle but also very important, primarily because the status of the myARCH downstream processing of a newly created/modified record is completely transparent to the REDCap GUI. Thus, no notification is given from within REDCap as to whether or not a record was successfully uploaded.

If an error occurs during downstream processing, the record can be re-saved in REDCap, which would trigger the myARCH downstream processing. (Assuming, of course, that there was a fixable issue that was resolved.)

For this release, myARCH processing status has to be ascertained at different levels. Here's a step-by-step progression:

Verify Survey Manager Published Survey Result

Notifications are provided in the myARCH container logs - see the administration section of the Installation and Administration Guide for how to access them. Once a survey has been completed, a successful pull of the REDCap record will produce several status messages, concluding with the following:

INFO org.chip.ihl.surveymanager.rest.controller.SurveyManagerController - Successfully pulled REDCap records and pushed to message queue.

Please refer to the myARCH Survey Manager Configuration Guide for other types of notifications that can be given (including error messages).

Verify ActiveMQ Received the Message

Do the following:

1. To use the management console connect to 'https://<myscilhs-host >/amq/admin/' in a browser. Use the username and password for the 'admin' user from the 'jetty-real.properties' file in the Survey Message Queue container.
2. Navigate to 'Queues' and find the 'myscilhs_patient_response' queue.
3. Verify the number of enqueued messages has increased.

Verify i2b2 Loader Received Message

Do the following:

1. To use the management console connect to 'http://<myscilhs-host >:8161/admin/' as described above.
2. Navigate to 'Queues' and find the 'myscilhs_patient_response' queue.
3. Verify the number of dequeued messages has increased.
4. To check in the i2b2Loader look at the log location specified by 'logback.xml'

5. You will see a message like the following:

   [ActiveMQ Session Task-1] DEBUG o.bch.myscilhs.consumer.I2B2Listener - Message Received: ... 

6. Verify the data was sucessfully loaded and not ignored by i2b2

Verify PDO file was Saved to i2b2 File System

1. Find the file location specified by i2b2 to store files (usually /opt/FR/<project name>)
2. Verify a file with a timestamp matching the message processing time is present.

Verify the Patient Data in i2b2

The patient data in PATIENT_MAPPING table should contain rows like rows 2 and 3 below. The PATIENT_NUM may be different as it is generated by i2b2, but the PATIENT_IDE='12345' must match in one row, and there should be a row with a PATIENT_IDE that matches the PATIENT_NUM of the row with the PATIENT_IDE = '12345'.

Verify the Event Data in i2b2

The event data in ENCOUNTER_MAPPING table should contain rows like rows 4 and 5 below. The PATIENT_IDE must match the PATIENT_IDE from the PATIENT_MAPPING table, '12345'.

Verify Observation Data in i2b2

The fact data in OBSERVATION_FACT table should contain many rows that match the ARCH PAH data from the survey . The PATIENT_NUM must match the PATIENT_NUM of PATIENT_IDE = '12345'