Let's take a look at the risks you're facing:
A hacker breaks into your server and steals the entire DB. Bad luck, in this case, encrypted references won't help much since the hacker likely got access to the key, too. Even if you completely federate the data, e.g. to different data centers, and the hacker only gets the 'anonymous' part of the data, those medical records will probably contain name, insurance and/or other identifying data. Even if not, there's research that shows that it's almost impossible to anonymize data (examples: anonymized friend graphs, device profiles)
A hacker hacks your site and gets access to data outside his account Since your server must be able to handle the de-referencing logic and must have access to both data stores to perform its duty, this method won't add security at all. However, since you're using a server technology that is completely new to you, the chances of having security holes in your software are high...
The disk crashes and you lose part of the data or the key In that case, you'll have more work to do than recovering from a similar scenario without encrypted references.
Making web applications safe boils down to one-and-a-half possibilities: Either make the system itself as robust as possible by using secure coding standards, penetration tests, intrusion prevention, two-factor authentication, etc., etc. and/or use client-side encryption. The latter looks like the ultimate weapon, but is fraught with its own perils. I'm afraid there's no silver bullet [that I can think of].