It depends on the nature of a business, which is clear to you but not us (OK, at least not me). F'rinstance your design suggests that a prescriber id can relate to many patients. However, if a patient can have more than one prescriber it is not correct. You then have a many to many relationship, not one to many as you've designed for. To handle many to many relationships you need 2 primary tables and one linking table (aka junction table). You might have other similar situations (e.g. dea to pharmacy). So without knowing the details of what the db is supposed to support, no one can definitively say whether or not you have it right just yet. A review of db normalization might be in order:
Normalization Parts I, II, III, IV, and V
http://rogersaccessblog.blogspot.com...on-part-i.html
and/or
http://holowczak.com/database-normalization/
Entity-Relationship Diagramming: Part I, II, III and IV
http://rogersaccessblog.blogspot.com...ng-part-i.html
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.