There is no issue. You have a total of 128GB of RAM which is actively utilizing 48GB for code execution. 74GB more is currently available for code execution. Buffering/caching is currently consuming that 74GB to optimize hard drive operations, but that memory can be freed at a moment's notice and reallocated for code execution.
What the healthcheck script is flagging is that at some point the system ran low on free memory and allocated 11GB in swap space. Whatever situation caused the low memory condition has abated, which is why there is now a healthy 74GB available for code execution allocation. However even after the low memory situation is resolved, any swap space allocated during that period is not relinquished back in anticipation of that situation possibly happening again, and that swap space will remain allocated until the next system boot.
There is no way to look only at the swap counters and determine when the low memory situation occurred or even if it is occurring right now (so the healthcheck script just reports it with no further context), however if the swap ballooning happened in the last 30 days you should be able to use the sar -S -f /var/log/sa/saXX command (XX is the day number of the month) to look back and see when the swap space allocation jumped. You could also see this using the historical mode of cpview with the -t option.
Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com