i haven't worked on Medical devices but i do pride myself on providing inline documentation with all my test framework code. I also tend to write them so that the tests that use them are a simple as possible so they don't need more description.
I have used sphinx quite a lot for this , it works realy nicely with python but other languages might have better tools. Once you have setup the basic environment for the documentation you can just add documentation stanzas in comments by each function , method , class or anything else. I then add a job in CI to build an extract the documentation each time there is a merge to master.
The best thing you can do with test documentation is plainly document why you are doing what you are doing with some indication of where you found out why that was what needed doing. Brutal honesty is more important than a polished product here because we need to know why behaviour happens.
In terms of tracability you can do this with most decent test management tools by quoting identifiers for specification documents in the code or the systems metadata. This will require maintenance in the form of periodic reviews, its a good idea to schedule these in so you don't forget and to enforce a limit to how much they can drift.
Ultimately you will have to write code to do a lot of this and you will need to make it as transparent and self documenting as possible.
