Data exchange engines exist to move documents or files from one system to another. For example, in healthcare,...
a data exchange occurs when a primary physician wants to see a patient's lab results or MRI done by another doctor or specialist. Data exchanges enable medical providers to securely pass patient information back and forth to provide better patient care and results.
As a patient moves through the healthcare system, his data follows him wherever he goes, forever. Even if a person moves across the U.S. or changes providers, his data stays with him. Testing data exchanges involves the ability to view, track and verify messages, message and data security, and the accuracy of the data object an end user receives.
Viewing, tracking and verifying messages. As a data exchange tester, having the ability to view messages at every transfer point during transit is essential. Testers need to verify the message when it first goes outbound and at each transfer point through to the final destination. The more accessible the message is to viewing and tracking, the better, at least for internal testing. The ability to view messages is essential to being able to fully test format and data integrity within the message. Only by viewing it do testers become familiar with the expected message format and content. Being familiar with message content makes it easier for testers to assist developers when troubleshooting issues in the message processing system.
Typically, messages are subject to regulatory auditing, so they leave a permanent "trail." Access to that trail is essential for testers to verify the quality of the message from beginning to end. Testers need to track performance from the time a message leaves a holding queue to when it arrives at each point and its final destination. If a business doesn't have access to more formal performance testing methods, testers can track expected times between message transfer points and locate performance issues.
Message and data security. Messages used for data exchanges have two main areas where security needs to be tested. The first is the security built into the message header in the form of a token, key or communication method that confirms the identity of the message. Additionally, the protocol (HTTPS) must be tested, as well as the certificate security to ensure everything functions together. Messages should be tested to ensure they cannot be accessed, intercepted or changed during transfer.
Frequently, application development businesses pay third-party security testing companies to thoroughly test message security. But it's imperative for the internal testing team to understand and be able to access and manipulate the data before sending the system out for third-party testing.
Many automated tools include basic security tests, but testers should spend time attempting to hack the messages at all points of transfer and receipt. Not only does it increase understanding of the internal system, but it allows creative testers to find unexpected defects before the system is in final development.
Testers also should be taught the inner workings of both tokens and certificates so security testing can be executed at any phase of development. Such knowledge offers testers an opportunity to understand internal security and stretch their creativity to find critical defects during the development cycle and before the system goes up against formal security testing. Detecting a problem earlier rather than later is always best.
Verifying the accuracy of the data objects an end user receives. Because the purpose of a data exchange engine is to provide an end user with a data object, the final test is that the user receives the expected object. Testers must verify not only that the data object was received but also that it is accessible, valid and accurate -- for example, verifying that a PDF version of a continuity of care document is in the expected PDF format and that it can be opened and viewed.
To verify data, the tester should have access to a variety of receiving systems, such as specific electronic health record, or EHR, applications. If that isn't possible, doing general tests to verify an object is received as expected is valid. Performing a risk analysis may be in order if the data exchange engine produces a lengthy list of valid formats and not all of them can be tested independently. Once a document is opened, the accuracy of the file must be verified. Is it for the correct patient? Does it contain expected information (e.g., medications, diagnoses, treatment)?
What to test next depends on which actions are allowed on the object. If the receiving system allows users to edit the object and save the edits, then you must verify the object can be successfully edited and saved. It's a good idea to reopen the document after saving an edit to verify it has not been corrupted and still functions as expected. Be certain to verify that any user actions that should be allowed are possible and that any user actions that should not be allowed are not.
What are the financial ramifications of data breaches?
Learn about how to manage failover testing procedures