Implementation includes a few different phases of testing to ensure your integration is up to par for your intended workflow(s). We describe each of these phases for you below. These descriptions are intended to guide you through the testing process, not replace test scripts or scenarios. We expect that you work with your connection to develop a test plan prior to kickoff.
The connectivity phase typically takes place immediately after the kickoff call and should be led by your connection's integration SME(s). During connectivity, we work directly with them to establish the appropriate method for exchanging data between your systems.
Remember that you're responsible for working with your connection to determine what each of you need to do to establish connectivity. We're here to help connect the dots for you, but make sure you share the appropriate resources with each other and with us to successfully start integrating.
If your data exchange method is HL7 using VPN, connectivity testing might look like this:
If your data exchange method is C-CDA using Client Cert TLS, connectivity testing might look like this:
Connectivity testing is complete when you're able to exchange data between Redox and your connection. If you're planning to use multiple methods of data exchange, all methods must be tested before moving to the next phase.
Functional unit testing is led by the Redox integration manager and builds on connectivity testing to test the in-scope data exchange methods. Metaphorically, you can think of connectivity testing like building the bridge between systems and now you can start driving the "vehicles" you expect to see cross the bridge. For example, if you're using the Redox Data Model API, you should test each data model and event type in scope; with the Redox FHIR® API, you should test each FHIR® resource and interaction/operation in scope.
Functional unit testing is an opportunity to confirm the expected data mapping, requirements, and translation. You and your connection can make adjustments accordingly after receiving the test messages from the integrated system. Most importantly, this confirms scope to see whether you can successfully accomplish all aspects of your workflow.
The functional unit testing phase is complete when you can answer "yes" to these questions:
Application testing is led by you and should go beyond basic sending and receiving to get into the nitty gritty of whether the data meets the needs of your system's unique workflow. During this phase, you should use test scripts to make sure:
For Basic and Standard plan customers, the Redox integration manager doesn't actively participate in the project anymore, but you can always submit an Application Testing ticket via our Help Desk if you need support. For Premium plan customers, your Redox integration manager stays involved through the end of go-live, but you should still plan to lead application testing.
The application testing phase is complete when you and your connection are confident in all aspects of your integration, including trigger events, data elements, and workflow fulfillment. Integration teams from both sides should feel confident in moving to production.
User acceptance testing (UAT) is an optional phase for training or testing workflows with end users of your system or your connection's system. You and your connection are responsible for organizing, planning, and executing any necessary user acceptance testing before go-live.
If you choose to perform UAT, the end users should go through the system workflow in a test environment to see whether the integration and data exchange would meet the needs of realistic use cases. This gives them the opportunity to ask questions, provide feedback, and familiarize themselves with new workflows.
Make sure to hold off UAT until all other testing is complete to avoid poor adoption of new tools or processes.
Production testing is a final chance to ensure that all workflows and data exchange are operating as expected. This is an optional phase in which workflows are completed in the production environment prior to making them public to end users.
This phase is completed at a scheduled time, often during off-hours, to ensure end users are not disrupted by the testing effort. This is the last step prior to go-live and is often completed days or hours prior to releasing the workflow to end users.