Schema Document
[ Home ] [ Up ]

Up
Data Relationship Examples
ODBC Driver Settings
Accounts
Appointments
Attorneys
Bills
Conditions
CPTCodes
Doctors
Employers
Facilities
Guarantors
ICDCodes
Patients
PatientCases
Payors
PersonalInjury
Profiles
Referrals
SOAP
StateForms
Submitters
WorkComp

In order to take advantage of the file layouts and field identifiers explained in this document, you must have the FairCom ODBC Driver loaded on your computer. This inexpensive driver (which is licensed per user by FairCom) can be purchased directly through HNA Computer Systems.

This document does not explain how to use ODBC or your report generator (e.g. Crystal Reports), load the FairCom drivers, or set up Microsoft ODBC Administration on your computer.

What this document is

Our objective is to explain the relationships among the ECLIPSE database files and define database fields so you can intelligently access the ECLIPSE database directly without using the ECLIPSE program.

Before you can access the ECLIPSE database through an ODBC compliant application, you must first purchase and install the Faircom ODBC Driver as noted above.

Table A file that contains a specific type of data (e.g. ICD codes).

Index A file that provides access to a table in a pre-defined order (e.g. alphabetized by last name).

Database Complete set of data tables used by ECLIPSE.

Member Individual record in a table (e.g. one attorney in ATTORNEYS).

Field Individual data in a member record such as first name, last name, etc.

Before we discuss the table hierarchy, it's important we review the relationships formed when data in one table is assigned to or associated with data in a second table. For example a service may be assigned to a specific doctor in the DOCTORS table and a specific facility in the FACILITIES table. In order to achieve this relationship, the record in the ACCOUNTS table stores the primary key information for the assigned doctor and facility.

Primary keys are unique identifiers which are unique to a specific record in a given data table. ECLIPSE generally uses numeric keys that can be assigned to various records. Thus, a payor such as AETNA may be assigned ID #23 (primary key in PAYORS). Dr. Steve Smith may be assigned ID #17 (primary key in DOCTORS). The Golden Years Nursing Home may be assigned ID #191 (primary key in the FACILITIES).

So, to continue with the above example, a service which is assigned to Dr. Smith when he visited a patient at the Golden Years Nursing Home will reflect the primary key information for the DOCTORS and FACILITIES table within this service record in the ACCOUNTS table.

Primary key relationships among the various files are the only way that data in one table can be associated with unique data in another.

Secondary tables such as ATTORNEYS, CPTCODES, DOCTORS, EMPLOYERS, FACILITIES, GUARANTORS, ICDCODES, etc. are generally indexed in both name and ID# order.

The primary patient file is PATIENTS. Each record in this file contains a patient name, address, phone #'s, social security #, etc., and represents a unique patient with a unique

numeric identification #. For each patient, multiple patient cases may exist in PATIENTCASES. In turn each patient case may be associated with a member of DOCTORS, EMPLOYERS, PROFILES, etc. as well as multiple members of ACCOUNTS, BILLS, and REFERRALS. Graphically, the relationship looks something like Figure 1.

Each arrow is a reference to a specific member in another data table. Note that these references are not physical. Thus, the John Smith member of PATIENTS does not carry a map that contains the location of related members in other tables. Rather, it contains the primary key information required to look up the requested member in an index associated with the table. This index is no different than an index you might have used at the local library to determine the location of a book you wanted to read.

• All patient related records (e.g. PATIENTCASES, ACCOUNTS, BILLS, etc.) have a primary index that includes a combination of the patient primary key (ECLIPSE assigned ID #) and case ID #. In the following sections, members that are also full or partial index keys are noted as KEY in red if the member is a key for the data in which it appears. A KEY to data in another table will appear in blue. If the member is a KEY for both the member and another table it will appear in green.
• Not all fields in the database are made public through ODBC. These fields are generally for internal use only.

The remaining sections of this guide discuss the members of each table alphabetically by table name. The following descriptors will be used within brackets ([ descriptor ]):

I Numeric field that only handles integer values (e.g. 1, 2, 3, 77, 1292, etc.).

Send mail to feedback@huntfamily.com with questions or comments about this web site.
Last modified: March 05, 2001