Concepts

<< Click to Display Table of Contents >>

Navigation:  Populating Members and Benefits >

Concepts

Previous pageReturn to chapter overviewNext page

Every row in EDI_CoveredMembers represents a single Member or Dependent. The distinguishing factor between subscriber and dependent is that a dependent has a value in the subscriber ID field, while both have a MemberID which is essential in the search. HIPAAsuite decided that for security and privacy reasons it is necessary to have the birth date of the patient whose benefits are requested. So Patient Name, ID and birth date have to match before benefit information can be found.

Every row in EDI_CoveredBenefits stores a single Benefit in its entirety. The Benefit itself is identified by its Service Type Code and MemberID, the primary key of the member table (not to be confused with the field "MemberID" in the CoveredMembers Table, tying the benefit to a specific member; there will be a single row for each Benefit (Service Type Code), of which many can be linked to a single Member or Dependent. This allows us to fully represent any Member's or Dependent's Eligibility and Benefit information in a database as compactly as possible without losing information.

 

The database schema of the Covered Membership files. MemberID is the foreign key to CoveredBenefits and it is the Auto-ID of CoveredMembers. 

The database schema of the Covered Membership files. MemberID is the foreign key to CoveredBenefits and it is the Auto-ID of CoveredMembers.