Data Anonymisation and Transformation Testing Process - TSFT to Deepmind

Transcription

1 Data Anonymisation and Transformation Testing Process - TSFT to Deepmind Taunton & Somerset NHS Foundation Trust Document Control This document is available in two forms, controlled and uncontrolled. The controlled variant is maintained electronically and accessed by authorised persons. Uncontrolled variants are all other electronic and printed copies. Document Approval Name Position Date Stuart Hill Luke Gompels Louise Coppin Deputy Chief Information Officer Chief Clinical Information Officer Information Governance Manager and Data Protection Officer Revision History Version Date Author Changes V0.1 29/09/2017 Julian Matthews Original Draft. V0.2 02/10/2017 Julian Matthews Minor revisions to wording within introduction and Test Point 1. V0.3 03/10/2017 Julian Matthews Minor revision following SH feedback, and attachment of dataflow document. V0.4 04/10/2017 Julian Matthews Clarification of which message types are in scope. V0.5 06/10/2017 Julian Matthews New test point added. V0.6 11/10/2017 Julian Matthews Correction to Merge Message Type, and addition of table in section 4 V0.7 16/10/2017 Julian Matthews Volumes of testing included within Test Point Descriptions V1.0 18/10/2017 Julian Matthews Final version. V1.1 01/11/2017 Julian Matthews Changes to Message types in line with PIA Page 1 of 6

2 Contents Document Control... 1 Document Approval... 1 Revision History Introduction Test Point 1 Confirm Consent Check Test Point 2 Confirm Message Filter Test Point 3 - Confirm Anonymization Test Point 4 - Confirm Message Integrity Test Point 5 - Confirm Connection to DMH Final Results... 6 Page 2 of 6

3 1 Introduction As part of the collaboration between Taunton and Somerset NHS Foundation Trust (TSFT) and Deepmind Health (DMH) for the Streams mobile app, TSFT will be securely sending fully anonymised records to DMH to simulate the existence of patients within the Mobile App Streams. To do this, TSFT will take 3 months of HL7 messages generated by the following systems: Electronic Patient Record - IMS Maxims Radiology System - Carestream RIS Pathology Results System - EMIS Review These HL7 messages will then be processed and anonymised within TSFT infrastructure before sending to DMH. This document demonstrates the testing processes in relation to the anonymization of data, and describes the scenarios for each of the Test Points as set out in the below document. Anoyimisation Deepmind v1.1.pdf The process of anonymising the records is detailed separately in the Data Anonymization Process v1.0 document, and will not be covered here. For each Test Point it is worth noting that each test will be completed in sequential order. For example, if Test Point 1 fails, the testing will not progress until the issues relating to the failure are corrected and retested. Only when the previous test passes will there be any progress. All results of testing will be documented. The testing has been planned so that the final test is the connection with DMH, and all other tests must be successful and testing outputs signed off by the CCIO, Caldicott Guardian, and IG Manager, before the link is established. This ensures full confidence in the processes tested before connecting to DMH infrastructure. In parallel to this document, the Privacy Impact Assessment (version TBC) describes the rationale for the data sharing and its use. 2 Test Point 1 Confirm Consent Check Test Point 1 is to ensure that the process of checking if the patient held within the record has withdrawn consent. The Trust Integration Engine (TIE) will extract the patient MRN from the message, and then check the MRN against those listed as withdrawing consent. To test this operating correctly, TSFT will add a fictitious patient MRN to the list, and pass a message through the process and observe the message not being processed due to the MRN being on the list. As there is the possibility that Pathology Results can exist without both a TSFT MRN number and NHS number, extra testing steps have been introduced to consider these variations. In the unlikely event that a result is found with neither of these ID number types, we abort the process as we are unable to confirm the consent status and must proceed assuming that the consent has been withdrawn. The following scenarios will be tested: Page 3 of 6

4 Message Type Description Expected Outcome Pathology Message MRN exists and is not listed as withdrawing Message passes through consent Pathology Message MRN exists and is listed as withdrawing Message is not passed through consent Pathology Message NHS number exists and is not listed as withdrawing consent Message passes through Pathology Message NHS number exists and is listed as Message is not passed through withdrawing consent Pathology Message Both NHS number and MRN not found so Message is not passed through consent check not possible Radiology Message Patient is not listed as withdrawing consent Message passes through Radiology Message Patient is listed as withdrawing consent Message does not pass through Maxims Message Patient is not listed as withdrawing consent Message passes through Maxims Message Patient is listed as withdrawing consent Message does not pass through 3 Test Point 2 Confirm Message Filter Only patient data that meets certain criteria (as defined in the PIA) will be considered in scope for transfer to DMH, therefore to prevent out of scope messages being transferred, TSFT will use the TIE to filter out specific HL7 messages based upon the Message Type recorded and the source of the result in the case of results data. Test Point 2 is intended to check that routing rules developed within the TIE operate as expected. To check this, 1000 example messages will be passed through the routing logic from each source. This will contain messages that are both expected to pass through, and expected to not pass through. The output will be checked to make sure only HL7 messages within scope are allowed through to the destination folder. This check will be completed by passing the example HL7 messages between two folders on an on-site server via the TIE s routing logic. Message Type Message Name Description Expected Outcome ADT^A01 Patient Admission Patient is admitted into A&E or as an inpatient to a ward ADT^A02 Patient Transfer Patient is transferred to a different ward. ADT^A03 Patient Discharge Patient is discharged from A&E or ward. ADT^A08 Update Admission Record Patient admission record has been updated. ORU^R01 Patient Result Patient Test/Radiology Results Page 4 of 6

5 4 Test Point 3 - Confirm Anonymization Test Point 3 is to ensure that the anonymization is operating as intended. To test this, TSFT will be taking 10 messages of each message type, anonymizing them, and then comparing them with the original messages using WinMerge. A successful result from this test would be for there to be no matching patient data between the original message and the anonymised counterpart as per the table below. Message Segment ID Expected Difference Description MSH.3.1 Difference In Data Sending application. MSH.4.1 Difference In Data Sending facility. MSH.5.1 Difference In Data Receiving application. MSH.6.1 Difference In Data Receiving facility. MSH.11.1 Difference In Data Processing ID. PID.2.1 Difference In Data Primary patient ID PID.2.5 Difference In Data Primary patient ID type. PID.3.* Difference In Data All patient ID numbers. PID.5.* Difference In Data Patient s names. PID.6.* Blank Field in Anonymized Message Mother s maiden name. PID.7.1 Difference In Data Date of Birth. PID.9.* Blank Field in Anonymized Message Patient Alias. PID.11.* Difference In Data Patient Addresses. PID.13.* Blank Field in Anonymized Message Patient Home Phone Numbers. PID.14.* Blank Field in Anonymized Message Patient Business/Work Phone Numbers. PID.15.* Blank Field in Anonymized Message Primary Language. PID.16.* Blank Field in Anonymized Message Marital Status. PID.17.* Blank Field in Anonymized Message Religion. PID.18.* Blank Field in Anonymized Message Patient Account Number. PID.19.* Blank Field in Anonymized Message Social Security Number. PID.20.* Blank Field in Anonymized Message Driving Licence. PID.21.* Blank Field in Anonymized Message Mother s Details. PID.22.* Blank Field in Anonymized Message Ethnicity. PID.23.* Blank Field in Anonymized Message Place of Birth. PID.24.* Blank Field in Anonymized Message Multiple Birth Indicator. PID.25.* Blank Field in Anonymized Message Birth order. PID.26.* Blank Field in Anonymized Message Citizenship. PID.27.* Blank Field in Anonymized Message Veterans Military Status. PID.28.* Blank Field in Anonymized Message Nationality. PID.29.1 Difference In Data Data of Death. NK1.* Blank Field in Anonymized Message Next of Kin. PD1.3 Difference In Data GP Practice Code PD1.4 Difference In Data GP Practitioner Code PD1.10 Blank Field in Anonymized Message Duplicate Patient information. Page 5 of 6

6 PD1.19 Blank Field in Anonymized Message Military Branch. PD1.20 Blank Field in Anonymized Message Military Rank. PD1.21 Blank Field in Anonymized Message Military Status. WinMerge is an Open Source program that can compare files and visually display the differences within the content of the message. The visual display s the two documents side by side and highlights the differences. 5 Test Point 4 - Confirm Message Integrity Test Point 4 is to ensure that the format/structure of the message has not been altered by the anonymization process and that the integrity of the data has been maintained, as this could result in issues with the testing of Streams. The comparisons will be against 10 messages of each message type and will be against the following segments: Segment RIS? Review? Maxims? Description MSG x x x Message Header PID x x x Patient ID PD1 x x Patient GP PV1 x x Patient Visit PV2 x Patient Visit ORC x x Common Order OBR x x Observation Request OBX x x Observation Result NTE x Notes And Comments *ZMP x Patient GP *ZPV x Request Location/Sample taker *These are custom segments used by the sending system to provide data which does not have its own available segment within the HL7 specification. 6 Test Point 5 - Confirm Connection to DMH Once Test Points 1-4 have been completed and have passed, TSFT will confirm that the TIE can connect to DMH. This connection will be via N3. To test the connection, the TIE will be configured to connect to the IP/Port number for DMH, and the connection will be enabled in isolation of the rest of the process to ensure no messages are sent inadvertently. The TIE will then complete a handshake with DMH to ensure the connection is working. If this fails, the TIE will notify technical staff via entries in the error log. 7 Final Results All of the results of the testing will be documented, including failures and the actions taken to correct issues found. Once all of the Test Points have completed testing, the outcome will be ed for internal sign-off by the CCIO, Caldicott Guardian, and IG Manager. No data will be transferred until internal sign-off has been achieved. Page 6 of 6