Scott, the trouble with sp_applock is that it's designed around single user - single process aspects. My understanding of the OP's question revolves around multiple dentists accessing multiple clients simultaneously, but he wants to make sure that none can step on the other's work.

Instead of rebuilding the wheel, there's another method of dealing with this but I personally hate it, because like the other method, so many things can go wrong. Just less moving parts.

Look into Transactions and Serializable isolation. What you'll be looking to do is have the application code control your transactions (and do NOT share connections) so that you begin this process by setting the connection to serializable isolation, then opening a transaction, then reading the particular rows you need from all tables. This share-locks them to that account. But, what you do during that read is force the exclusive lock via join hints.

From there, you let them do their work and close the transaction when they're done.

Be aware, however, that this is NOT as granular as you think it is. This approach can hose you up very quickly depending on how much data you're pulling, as you won't be doing just row locks, but page and table locks because of the way memory and data storage is managed in SQL Server. It requires JUST as much testing and even more optimization than the other method to make sure you're locking as little as possible for each user's access.

So, since we've been telling you just how hard this could be, let me make a recommendation for a much easier to approach method that is less likely to shoot you in both feet.

Start with adding a last access datetime column to all the tables that you're looking to lock for a particular user's modification. Pull said data for the user. When they choose to edit any data, have the system go through and check to make sure noone's tried to edit in the last five minutes via this column, then update all the records just for the datetime piece. Have your code disallow editing to proceed blindly after five minutes, where it would have to go through and re-check the timestamps (to make sure another user didn't come in while they got their coffee and talked to the assistant) to make sure their allowable edits are still valid. If they're still allowed, let them commit the changes.

Does this do exactly what you were looking for? No. But it is MUCH easier to implement and much less likely to end up with your system locked out requiring massive developer involvement to get the production system to re-release. At worst, everyone just has to wait five minutes.