Think about it this way: The probability of your auditor being a software developer is low (yes, I was also surprised to learn this). If they were a software developer, that’s probably a few decades ago and their last programming experience included punch cards and mainframes.
Sarcasm aside, you could approach this problem from another angle: What would be the most efficient way for an auditor to understand what your software does? Probably not by reading your code. Maybe by using the software. But that’s also something which is not typically done. It might also require specific medical experience and/or a specific setting (say, being in an Operating Room).
No, the most efficient way (so far?) is to read through your documentation, specifically your software requirements. Ideally, those should provide even an uninitiated reader with an overview of the behavior of your software. In addition, you need to document your software architecture and tests, your auditor is also going to look at those.
