Given that I'll use a natural key, how do I deal with the situation if I find out the value later?

Question

I have been doing a lot of reading about the pros and cons of using natural versus surrogate keys.  I have read in Joe Celko's books and his writing online that he strongly opposes using surrogate keys and using IDENTITY for generating values for a
surrogate key column of a table in SQL Server.  I would like some advice on how to handle this situation:  I have a table with physician information and would like to use their NPI as a natural key (it would be a foreign key in many other tables)
but the people who enter new physicians often don't know the NPI until later.  They also may receive the wrong NPI and need to change it later.
Right now they use Excel spreadsheets to manage their data and I'm sure you can understand what a nightmare of data integrity that is.  Now that I'm going to design and build a database for them, can you recommend a good approach to this specific problem?
 I cannot tell them to hold on to the new physician's data until they get the NPI because they need to immediately work with the physician's information as soon as the new physician joins the organization.  It's a small shop and not a health system
but thousands of physicians join.  They cannot insist that the NPI be supplied at the time of registration for various political reasons.  The people who are using the system now have varying degrees of skepticism to outright vehement opposition
to having a new database system so I cannot "lay down the law" about things that may adversely affect the relationship with the new physicians who sign up.  With the Excel spreadsheets they cope with this by either leaving it blank, entering
9999999 or some other stray string of characters, or perhaps typing in their shopping list.
Is there a viable solution to this design problem?  Any and all suggestions appreciated.  Thanks for reading this.

Answer 1

While I disagree with the standard practice of adding an identity column as the primary key for every table, I think that this is a case where it can be beneficial or practical.  You might not want to cluster on the identity column and you still need
to enforce the uniqueness of the natural key. 
OTOH, the alternative is to simply fabricate a value for the natural key when it is unknown.  You could do this manually (where the user must enter the fabricated value) or automatically (where the server generates it).  A manual approach might
be frustrating to the users since they have to "guess" what would be unique and acceptable, resulting in sort of trial-and-error approach to adding.  You would also very likely need to have a way of identifying which rows had a fabricated value.  Once
the actual natural key has been identified for a given provider you would then need to update it.  The server can handle cascading the value where needed if you so choose.  Note that, except for the cascading part, you need the same capabilities
for an identity-based table since this natural key is most likely essential to the system. 
I'll also point out that you can use a unique constraint as the target of a foreign key - you don't have to use the primary key.  Not recommending this, just mentioning the alternative.  
Which you should choose I can't say - that requires a much better understanding of your model and that isn't something that can be readily provided in a forum such as this.  I will say that you should not prematurely choose an identity.  Why?  First,
you make this choice once you have deemed the natural key to be a problem.  Second, it may be (at least) some of your anticipated relationships to physician are actually to something else.  A medical system is as much art as science - at least in
the USA.  Providers, plans, participants, terms, renewals, diagnosis codes, etc. make one's head spin.  Given that you have just started modeling, there is no reason at this point to make this choice - just be aware that the natural key poses some
issues that you need to address at some point before completion.  Personally I would choose the natural key for now and let the model develop and demonstrate where this choice becomes a problem.