Without seeing an execution plan or ddl, I the below are just guesses.
Depending on the number of rows returned by your nested select, you may get better performance by changing your WHERE statement. How specifically you change it depends on how many rows you get back with the nested select. MAY get better performance by changing it to a JOIN if possible rather than in your WHERE clause, but this depends on what that function is doing.
If the data doesn't need to be ordered, removing the order by and ordering it at the application side may give you a performance boost.
If the data is not duplicated in any rows, removing the DISTINCT will give a performance boost.
Depending on various factors, having it run parallel or run single threaded may help performance.
The above is all guesswork though as we can't see your data, your execution plan, indexes, or anything... just the one query... It could be that your function expects an INT and you are passing a VARCHAR, so having the input types match and not having the implicit conversion MAY help performance too.
Now, a non SQL way to make it faster - faster disk, faster network, more CPU, more memory <-- any of these MAY make it faster.
Making History an in-memory table MAY make it faster too. Populating a temp table or table variable with the function data MAY give better performance too.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.