We shared recently that Healthcare IT integration is far from a straightforward process. The minutiae associated with system integration projects is far-reaching, and can seem insurmountable without the right technical partners to oversee every little deal, respecting that a single variable can lock up the entire build. One of the key phases in any integration effort is end-to-end testing. Especially when access to critical patient information is at stake, connecting health systems requires so much more than just technical agreement. Detailed testing of patient data and results flowing correctly and expediently from one component to the next must be done in a systematic, unapologetic manner to call an integration effort complete and successful.
Let’s discuss why this last step must never be rushed through or haphazardly conducted by overly-invested project resources, and how you can position your healthcare organization to fare well post-integration.
Best-Case Scenario Isn’t Reality
The problem that we often see with UAT or testing efforts in the wake of a new system integration -- however large or small in scale -- is that an unrealistic set of data or records are being used to establish success. Cherry-picking simple files or those that are more representative of the perfect (but rare) workflow is not going to establish that the interoperability is truly ironclad enough to let loose on the organization as a whole.
A more prudent data set for comprehensive end-to-end testing is one that includes expected, normal workflows, as well as those that include data that would be a “stress” to the integrated components. What this looks like varies given the systems that are plugged together for the first time, but it’s nevertheless important to include less-than-perfect records to see how the new build will handle them. Data loss is generally the biggest concern/risk, so making sure that there are no gaps and that exception files are retrievable is key.
Include End Users In Designing Test Scenario
The most dirty word in healthcare IT is should. When there are assumption about how a program or tool will be used, versus verifying
the actual use cases and workflows, there will be barriers to implementation. Including the actual end users who will interact with the new records/data in developing testing plans is the more surefire way to feel confident that integration of healthcare IT components actually worked as architected. Relying on mid- to senior-level resources who rarely have their hands on the actual clinical information in question is a subpar way to validate results.
In the absence of mock (but realistic) data and documented (again, realistic) workflows for the anticipated end users, testing becomes a cycle of self-fulfilling prophecy on the part of the project team. There must be no fear of testing; or more precisely, there musn’t be fear of discovering there is still work to do.
Limited Testing Cycles Will Give Limited Confidence In System Readiness
Executing a handful of well-orchestrated testing cycles generally accomplishes little more than checking a box on the project To-Do list. There are many variables that contribute toward the behavior of a living technology system for health organizations, and if testing isn’t attempting to replicate as many of those factors as humanly possible, then you’re missing the mark. (Utilizing what is mechanically possible via automated test cases is even better, but we never advocate bypassing the value of a knowledgeable human tester.)
Perhaps data seems to flow just fine, but suddenly there is a spike in users and the load balancer craps out. Users can’t login, some are stuck, and records in transit are MIA. Perhaps the AD wasn’t properly configured, and only the carefully determined UAT team can get into the system on Go-Live day. Whoops. Or maybe a rare-but-possible file type is exchanged and the API freaks out, shutting down all end points and rendering the integration stalled in its entirety.
Testing Best Practices: Try To Break The Thing
End-to-end integration testing should absolutely organized and civilized, but there is also a lot to be said for getting a little savage on the build. Some of the best testers in the business can find a bug in any given workflow. The project team may grow to resent this resource, but the organization dependent on the new integrated system should value them as gold. When that tester finally sends the all clear, you can be confident that your efforts were well-done, and the likelihood of smooth implementation is great increased.