Implementation includes a few different phases of testing to make sure 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. You should work with your connection to develop a test plan before 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 HL7v2 using VPN, connectivity testing might look like this:
- Your Redox integration manager shares VPN web form link with your connection's team.
- Your connection completes the VPN web form, which is automatically submitted back to the Redox integration manager.
- The Redox integration manager submits a ticket to our technical onboarding team to create one side of the VPN tunnel. Once complete, we send the VPN settings and pre-shared key (PSK) to your connection's team to stand up the other end of the tunnel.
- Once both sides of the VPN tunnel are created, both sides perform connectivity testing.
If your data exchange method is C-CDA using Client Cert TLS, connectivity testing might look like this:
- Your Redox integration manager shares our SOAP endpoint with your connection's team. This is the destination that they can send C-CDAs to.
- Your connection's team shares the public client certificate with the Redox integration manager, which we load into Redox.
- Both sides perform connectivity testing.
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, connectivity testing is like building the bridge between systems and test driving the "vehicles" you expect to see cross the bridge. For example, if 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.
- Your connection's team triggers in-scope outbound messages from their system and the Redox integration manager confirms receipt within Redox.
- Your Redox integration manager confirms that the message structure includes all Redox-required elements and normalizes appropriately. They make any necessary updates within Redox to successfully ingest the message. Or, they may ask your connection's team to update unexpected data structures or formats that can't be normalized (e.g., updating MSH-11 of HL7 messages to a “T” instead of a “P” since “P” typically indicates a production message).
- Your Redox integration manager pushes the message to your system.
- Your system receives the message.
- You send a 200 response back to Redox and confirm all required data elements are present. If there are any data elements missing, work with your Redox integration manager to find out if the data is missing or isn't mapped correctly.
- Repeat this process for all message types from your connection until you're confident all of the required data can be exchanged appropriately.
- Your system triggers in-scope messages from your system to Redox with your connection's appropriate destination ID(s) and all Redox-required data elements in the payload. For data model requirements, refer to our data model docs. For FHIR® requirements, refer to our FHIR® resources.
- Your Redox integration manager confirms that the message structure includes all Redox-required elements. They make any necessary updates within Redox to successfully ingest the message or ask your team for additional information.
- Your Redox integration manager normalizes the message to the requested format and pushes it to your connection's system.
- Your connection receives the message, sends the appropriate response to Redox given the integration method, and confirms that all expected data elements are present. If any data elements are missing, your connection's team should request that you add the data and try resending. Your Redox integration manager makes the appropriate updates to the inbound mappings and pushes the message again.
- Repeat this process for all message types from your system until you're confident all of the required data can be exchanged appropriately.
The functional unit testing phase is complete when you can answer "yes" to these questions:
- Can your system successfully send or request data for all in-scope methods? Did you confirm that the expected data elements were present and mapped appropriately?
- Can your system successfully receive or respond to all in-scope methods? Did you confirm that the expected data elements were present and mapped appropriately?
- Can your connection answer "yes" to these questions, too?
Application testing is led by you and should go beyond basic sending and receiving. You should get into the nitty gritty of whether the data meets the needs of your system's unique workflow. Check out our developer downloads to help with your application testing.
During this phase, you should use test scripts to make sure:
- Your workflows can be completed end-to-end.
- Your workflows are tested in a way that mirrors how they should be accomplished in production.
- Any received messages contain all the required information in the correct and expected format.
- Any edge cases are accounted for and behaving as expected.
Depending on the platform support tier you purchased, the Redox integration manager may or may not actively participate in the project anymore. Your Redox integration manager may stay involved through the end of go-live, but you should still plan to lead application testing. If you purchased a lower platform support tier, you can always submit an Application Testing ticket via our Help Desk for additional support.
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, end users should go through the system's 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 on UAT until all other testing is complete to avoid poor adoption of new tools or processes.
Production testing is a final chance to make sure that all workflows and data exchange are operating as expected. This is an optional phase in which workflows are completed in the production environment before making them public to end users.
This phase is completed at a scheduled time, often during off-hours, to make sure end users aren't disrupted by the testing effort. This is the last step before go-live and is often completed days or hours before releasing the workflow to end users.
FHIR® is a registered trademark of Health Level Seven International (HL7) and is used with the permission of HL7. Use of this trademark does not constitute an endorsement of products/services by HL7®.