If I read this problem correctly, the answer is either "you can't do this at all" or "you don't really want to do it this way."
If you have distinct tables that are structurally different depending on Inpatient/Outpatient status, and your patient number is an Autonumber, you will run the risk of overlapping numbers. Forcing a table to have a starting autonumber other than 1 is possible but Access is cantankerous at best about such things. Autonumbers tend to be reset too quickly. You would be unable to survive the "overlapping number" case.
If I read this correctly further between the lines, you are using this as a backup system to store data somewhere until another system comes back online. So my question is, how do you reconcile data between Access and the other system once it is back online? I think the resolution of number differences would have to be resolved at reconciliation time, not at initial data capture time.
Now, having rained on your parade, I'll suggest a way you can muddle through.
On your data entry form, make the Inpatient/Outpatient selector one of the first things you click. Capture everything you can that is common to both patient classes. Then when you need to do it, open one of two subforms depending on the state of that In/Out box. Collect only the stuff specific to patient type in that form.
In the subform, you might have to get kinky here. Make the common data have a single autonumber. Store the autonumber from the common data in the Inpatient table or the Outpatient table, whichever is applicable.
Since the relationship is sort of "backwards" with respect to your detail tables, your parent/child relationship must allow for "all Inpatients and any matching common parts", ditto for Outpatients. Now you have two tables, each of which is actually one-to-one with the common patient record. But because it is an either-or relationship, you cannot make it one-to-one. Technically, this is a SPARSE relationship. I.e. not fully populated.
How you reconcile this back to your master system is going to be tricky. I'll say this: You CANNOT establish a one-to-one relationship in which the common data portion refers to an autonumber from the type-specific portion. That would give you non-unique relationships.
Said another way, you cannot link parent-to-child in this context - but you could still link child-to-parent and just write your queries somewhat backwards.
On the other hand, if this is all an effort to retrofit something as a fallback to a larger system, you shouldn't have any trouble if you simply replicate the schema (on a smaller scale) of the target system for which you are providing the fallback. If their system can provide relational integrity, so can you (for the most part.) And if they CAN'T provide that integrity, then you shouldn't have to, either.
