Home/ Questions/Q 8079505
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-05T16:07:27+00:00

I’m building a claims database with the above schema so far. Three three-part key

  • 0

enter image description here

I’m building a claims database with the above schema so far. Three three-part key on tblPatient is to uniquely identify individual’s claim for a certain problemX. The same patientID can appear in tblPatient as long as the admission/discharge dates are different.

This database is also concerned (not pictured) with claims that are NOT associated with problemX. These claims will be identified with another three-part key of patientID, claimsFromDate,claimsThroughDate. So, tblPatient.admissionDate and tblPatient.DischargeDate will not have to be equal to claimsFromDate and claimsThroughDate and if they are equal it’s happenstance.

Since tblPatient.patientID is repeated more than once (for those that have more than one visit), I cannot simply copy it to another table without breaking unique constraints for a primary key. I need to be able to relate patientID with the rest of the claims. Do I need to redesign my tblPatient to only have one field as a primary key, or include the already-existing three-part key and just roll with it?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    First of all: In a perfect, puristic, database-world you would split your patients database into two – one containing the patients, and another called “PatientClaims” or such. If you do not care for patient-specifc data apart from patient-ID, then you should at least rename the table.

    That same puristic approach would also tell you the primary key is defined as “The only set of data that uniquely identifies the row” – which is likely your three fields. (I could assume that you could leave out DischargeDate, but only if you are sure that the logic for doing so is sound)

    Seeing, however, that you have to work with:
    1. A three-part key, which is never pleasent
    2. Having that key-combo across two tables, and likely having to join them

    I would suggest simply defining a new key – like “ClaimID” using whatever autoincrement functions your database of choice has available.

    Unrelated note: Your whole state/county double-table set looks kinda weird – but that might just be me not understanding what you are modelling.

    • 0