Used in the accounting section in chart of accounts. Not related to patient accounts in any way. Primary key. . Enum:AccountType Asset, Liability, Equity,Revenue, Expense Used in accounting for chart of accounts. 0 1 2 3 4 For asset accounts, this would be the bank account number for deposit slips. Set to true to not normally view this account in the list. .
In the accounting section, this automates entries into the database when user enters a payment into a patient account. This table presents the user with a picklist specific to that payment type. For example, a cash payment would create a picklist of cashboxes for user to put the cash into. Primary key. FK to definition.DefNum. FK to account.AccountNum. AccountNums separated by commas. No spaces.
An adjustment in the patient account. Usually, adjustments are very simple, just being assigned to one patient and provider. But they can also be attached to a procedure to represent a discount on that procedure. Attaching adjustments to procedures is not automated, so it is not very common. Primary key. The date that the adjustment shows in the patient account. Amount of adjustment. Can be pos or neg. FK to patient.PatNum. FK to definition.DefNum. FK to provider.ProvNum. Note for this adjustment. Procedure date. Not when the adjustment was entered. This is what the aging will be based on in a future version. FK to procedurelog.ProcNum. Only used if attached to a procedure. Otherwise, 0. Timestamp automatically generated and user not allowed to change. The actual date of entry.
Appointments can show in the Appointments module, or they can be on the unscheduled list. An appointment object is also used to store the Planned appointment. The planned appointment never gets scheduled, but instead gets copied. Primary key. FK to patient.PatNum. The patient that the appointment is for. Enum:ApptStatus . Appointment status. 0- No appointment should ever have this status. 1- Shows as a regularly scheduled appointment. 2- Shows greyed out. 3- Only shows on unscheduled list. 4- Functions the same as Scheduled for now. 5- Shows with a big X on it. 6- Planned appointment. Only shows in Chart module. User not allowed to change this status, and it does not display as one of the options. Time pattern, X for Dr time, / for assist time. Stored in 5 minute increments. Converted as needed to 10 or 15 minute representations for display. FK to definition.DefNum. This field can also be used to show patient arrived, in chair, etc. The Category column in the definition table is DefCat.ApptConfirmed. Amount of time to add to appointment. Example: 2 would represent add 20 minutes. FK to operatory.OperatoryNum. Note. FK to provider.ProvNum. FK to provider.ProvNum. Optional. Only used if a hygienist is assigned to this appt. Appointment Date and time. If you need just the date or time for an SQL query, you can use DATE(AptDateTime) and TIME(AptDateTime) in your query. FK to appointment.AptNum. A better description of this field would be PlannedAptNum. Only used to show that this apt is derived from specified planned apt. Otherwise, 0. FK to definition.DefNum. The definition.Category in the definition table is DefCat.RecallUnschedStatus. Only used if this is an Unsched or Planned appt. Enum:LabCase A lab case is expected for this appointment. Used in the appointment edit window. 0 1 2 3 This is the first appoinment this patient has had at this office. Somewhat automated. A one line summary of all procedures. Can be used in various reports, Unscheduled list, and Planned appointment tracker. Not user editable right now, so it doesn't show on the screen. FK to employee.EmployeeNum. You can assign an assistant to the appointment. FK to instructor.InstructorNum. Only used in dental schools. FK to schoolclass.SchoolClassNum. Only used in dental schools. FK to schoolcourse.SchoolCourseNum. Only used in dental schools. Dental School field. eg 3.5. Only a grade for this single appointment. The course grade shows on a report. FK to clinic.ClinicNum. 0 if no clinic. Set true if this is a hygiene appt. The hygiene provider's color will show.
For now, the rule is simple. It simply blocks all double booking of the specified code range. The double booking would have to be for the same provider. This can later be extended to provide more complex rules, such as partial double booking, time limitations, etc. Primary key. The description of the rule which will be displayed to the user. The procedure code of the start of the range. The procedure code of the end of the range. Usually true. But this does allow you to turn off a rule temporarily without losing the settings.
Enables viewing a variety of operatories or providers. This table holds the views that the user picks between. The apptviewitem table holds the items attached to each view. Primary key. Description of this view. Gets displayed in Appt module. Order to display in lists. Every view must have a unique itemorder, but it is acceptable to have some missing itemorders in the sequence. Number of rows per time increment. Usually 1 or 2. Programming note: Value updated to ContrApptSheet.RowsPerIncr to track current state.
Each item is attached to a row in the apptview table. Each item specifies ONE of: OpNum, ProvNum, or Element. The other two will be 0 or "". Primary key. FK to apptview. FK to operatory.OperatoryNum. FK to provider.ProvNum. Must be one of the hard coded strings picked from the available list. If this is a row Element, then this is the 0-based order. If this is an element, then this is the color.
An autocode automates entering procedures. The user only has to pick composite, for instance, and the autocode figures out the code based on the number of surfaces, and posterior vs. anterior. Autocodes also enforce and suggest changes to a procedure code if the number of surfaces or other properties change. Primary key. Displays meaningful decription, like "Amalgam". User can hide autocodes This will be true if user no longer wants to see this autocode message when closing a procedure. This makes it less intrusive, but it can still be used in procedure buttons.
AutoCode condition. Always attached to an AutoCodeItem, which is then, in turn, attached to an autocode. Primary key. FK to autocodeitem.AutoCodeItemNum. Enum:AutoCondition 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Corresponds to the autocodeitem table in the database. Primary key. Foreign key to AutoCode.AutoCodeNum Foreign key to ProcedureCode.ADACode
Corresponds to the benefit table in the database which replaces the old covpat table. A benefit is usually a percentage, deductible, limitation, max, or similar. Each row represents a single benefit. A benefit can have a value in EITHER PlanNum OR PatPlanNum. If it is for a PlanNum, the most common, then the benefit is attached to an insurance plan. If it is for a PatPlanNum, then it overrides the plan benefit, usually a percentage, for a single patient. Benefits we can't handle yet include posterior composites, COB duplication, amounts used, in/out of plan network, authorization required, missing tooth exclusion, and any date related limitations like waiting periods. We also cannot yet handle family level benefits. All benefits are at the individual patient level. Here are examples of typical usage which parallel X12 usage. Example fields shown in this order: CovCat, ADACode(- indicates blank), BenefitType, Percent, MonetaryAmt, TimePeriod, QuantityQualifier, Quantity Annual Max $1000: General,-,Limitations,0,1000,CalendarYear,None,0 Restorative 80%: Restorative,-,Percentage,80,0,CalendarYear,None,0 $50 deductible: General,-,Deductible,0,50,CalendarYear,None,0 Deductible waived on preventive: Preventive,-,Deductible,0,0,CalendarYear,None,0 1 pano every 5 years: General(ignored),D0330,Limitations,0,0,Years,Years,5 2 exams per year: Preventive(or Diagnostic),-,Limitations,0,0,BenefitYear,NumberOfServices,2 Fluoride limit 18yo: General(ignored), D1204, Limitations, 0, 0, CalendarYear(or None), AgeLimit, 18 (might require a second identical entry for D1205) 4BW every 6 months: General(ignored), D0274, Limitations, 0, 0, None, Months, 6. The text above might be difficult to read. We are trying to improve the white spacing. Primary key. FK to insplan.PlanNum. Most benefits should be attached using PlanNum. The exception would be if each patient has a different percentage. If PlanNum is used, then PatPlanNum should be 0. FK to patplan.PatPlanNum. It is rare to attach benefits this way. Usually only used to override percentages for patients. In this case, PlanNum should be 0. FK to covcat.CovCatNum. Corresponds to X12 EB03- Service Type code. Can never be blank. There will be very specific categories covered by X12. Users should set their InsCovCats to the defaults we will provide. FK to procedurecode.ADACode. Typical uses include fluoride, sealants, etc. If a specific code is used here, then the CovCat is completely ignored. Enum:InsBenefitType Corresponds to X12 EB01. Examples: 1=Percentage, 2=Deductible, 3=CoPayment, 4=Exclusions, 5=Limitations. There's not really any difference between limitations and exclusions as far as the logic is concerned. Used in the benefit table. Corresponds to X12 EB01. 0- Not usually used. Would only be used if you are just indicating that the patient is covered, but without any specifics. 1- This corresponds to the X12 Co-Insurance type. Except it's the opposite because it's the insurance coverage percentage, whereas X12 sends the percentage as the patient's responsibility portion. 2- The deductible amount. Might be two entries if, for instance, deductible is waived on preventive. 3- A dollar amount. 4- Services that are simply not covered at all. 5- Covers a variety of limitations, including Max, frequency, fee reductions, etc. Only used if BenefitType=Percentage. Valid values are 0 to 100. Used for CoPayment, Limitations, and as deductible in PercentDeduct. Enum:BenefitTimePeriod Corresponds to X12 EB06, Time Period Qualifier. Examples: 0=None,1=ServiceYear,2=CalendarYear,3=Lifetime,4=Years. Might add Visit and Remaining. Used in the benefit table. Corresponds to X12 EB06. 0- A timeperiod is frequenly not needed. For example, percentages. 1- The renewal month is not Jan. In this case, we need to know the effective date so that we know which month the benefits start over in. 2- Renewal month is Jan. 3- Usually used for ortho max. 4- Wouldn't be used alone. Years would again be specified in the quantity field along with a number. Enum:BenefitQuantity Corresponds to X12 EB09. Not used very much. Examples: 0=None,1=NumberOfServices,2=AgeLimit,3=Visits,4=Years,5=Months Used in the benefit table in conjunction with an integer quantity. 0- This is used a lot. Most benefits do not need any sort of quantity. 1- For example, two exams per year 2- For example, 18 when flouride only covered to 18 y.o. 3- For example, copay per 1 visit. 4- For example, pano every 5 years. 5- For example, BWs every 6 months. Corresponds to X12 EB10. Qualify the quantity
Every InsPlan has a Carrier. The carrier stores the name and address. Primary key. Name of the carrier. . Second line of address. . 2 char in the US. Postal code. Includes any punctuation. E-claims electronic payer id. 5 char. Do not send electronically. It's just a default; you can still send electronically.
The claim table holds information about individual claims. Each row represents one claim. Primary key FK to patient.PatNum Usually the same date as the procedures, but it can be changed if you wish. Usually the date it was created. It might be sent a few days later if you don't send your e-claims every day. Single char: U,H,W,P,S,or R. U=Unsent, H=Hold until pri received, W=Waiting in queue, P=Probably sent, S=Sent, R=Received. A(adj) is no longer used. Date the claim was received. FK to insplan.PlanNum. Every claim is attached to one plan. FK to provider.ProvNum. Treating provider. Total fee of claim. Amount insurance is estimated to pay on this claim. Amount insurance actually paid. Deductible applied to this claim. The preauth number received from ins. Single char for No, Initial, or Replacement. Date prior prosthesis was placed. Note that this is only for paper claims. E-claims have a date field on each individual procedure. Note for patient for why insurance didn't pay as expected. Note to be sent to insurance. Max 255 char. E-claims also have notes on each procedure. "P"=primary, "S"=secondary, "PreAuth"=preauth, "Other"=other, "Cap"=capitation. Not allowed to be blank. Might need to add "Med"=medical claim. FK to provider.ProvNum. Billing provider. Assignment can be automated from the setup section. FK to referral.ReferralNum. Referral number for this claim. Enum:PlaceOfService . 0. CPT code 11 1. CPT code 12 2. CPT code 21 3. CPT code 22 4. CPT code 31 5. CPT code 33 6. CPT code ? 7. CPT code 15 8. CPT code 03 9. CPT code 26 10. CPT code 50 11. CPT code 71 12. CPT code 72 blank or A=Auto, E=Employment, O=Other. Date of accident, if applicable. Accident state. Enum:YN . Unknown,Yes, or No. 0 1 2 True if is ortho. Remaining months of ortho. Valid values are 1-36. Date ortho appliance placed. Enum:Relat Relationship to subscriber. The relationship is copied from InsPlan when the claim is created. It might need to be changed in both places. Relationship to subscriber for insurance. 0 1 2 3 4 5 6 7 8 FK to insplan.PlanNum. Other coverage plan number. 0 if none. This provides the user with total control over what other coverage shows. This obviously limits the coverage on a single claim to two insurance companies. Enum:Relat The relationship to the subscriber for other coverage on this claim. Relationship to subscriber for insurance. 0 1 2 3 4 5 6 7 8 Sum of ClaimProc.Writeoff for this claim. The number of x-rays enclosed. FK to clinic.ClinicNum. 0 if no clinic.
Stores the information for printing different types of claim forms. Each claimform has many claimformitems attached to it, one for each field on the claimform. This table has nothing to do with the actual claims. It just describes how to print them. Primary key. eg. ADA2002 or CA Medicaid If true, then it will not be displayed in various claim form lists as a choice. Valid font name for all text on the form. Font size for all text on the form. For instance OD12 or JoeDeveloper9. If you are a developer releasing claimforms, then this should be your name or company followed by a unique number. This will later make it easier for you to maintain your claimforms for your customers. All claimforms that we release will be of the form OD##. Reports that the user creates will have this field blank, protecting them from being changed by us. So far, we have built the following claimforms: ADA2002=OD1, Denti-Cal=OD2, ADA2000=OD3, HCFA1500=OD4, HCFA1500preprinted=OD5, Canadian=OD6, Belgian=OD7 Set to false to not print images. This removes the background for printing on premade forms. Shifts all items by x/100th's of an inch to compensate for printer, typically less than 1/4 inch. Shifts all items by y/100th's of an inch to compensate for printer, typically less than 1/4 inch.
One item is needed for each field on a claimform. Primary key. FK to claimform.ClaimFormNum If this item is an image. Usually only one per claimform. eg ADA2002.emf. Otherwise it MUST be left blank, or it will trigger an error that the image cannot be found. Must be one of the hardcoded available fieldnames for claims. For dates, the format string. ie MM/dd/yyyy or M d y among many other possibilities. The x position of the item on the claim form. In pixels. 100 pixels per inch. The y position of the item. Limits the printable area of the item. Set to zero to not limit. Limits the printable area of the item. Set to zero to not limit.
Each row represents a single check from the insurance company. The amount may be split between patients using claimprocs. The amount of the check must always exactly equal the sum of all the claimprocs attached to it. There might be only one claimproc. Primary key. Date the check was entered into this system, not the date on the check. The amount of the check. The check number. Bank and branch. Note for this check if needed. FK to clinic.ClinicNum. 0 if no clinic. FK to deposit.DepositNum. 0 if not attached to any deposits. Descriptive name of the carrier just for reporting purposes.
Links procedures to claims. Also links ins payments to procedures or claims. Also used for estimating procedures even if no claim yet. Warning: One proc might be linked twice to a given claim if insurance made two payments. Many of the important fields are actually optional. For instance, ProcNum is only required if itemizing ins payment, and ClaimNum is blank if Status=adjustment,cap,or estimate. Primary key. FK to procedurelog.ProcNum. FK to claim.ClaimNum. FK to patient.PatNum. FK to provider.ProvNum. Fee billed to insurance. Might not be the same as the actual fee. The fee billed can be different than the actual procedure. For instance, if you have set the insurance plan to bill insurance using UCR fees, then this field will contain the UCR fee instead of the fee that the patient was charged. Actual amount this carrier is expected to pay, after taking everything else into account. Considers annual max, override, percentAmt, copayAmt, deductible, etc. This estimate is computed automatically in TP module, and gets overwritten when sent to ins. Deductible applied to this procedure only. If not sent to ins yet, then this will be set to an estimated amount based on the order in the TP. Will be overwritten when actually sent to ins. Enum:ClaimProcStatus . Claimproc Status. The status must generally be the same as the claim, although it is sometimes not strictly enforced. 0: For claims that have been created or sent, but have not been received. 1: For claims that have been received. 2: For preauthorizations. 3: The only place that this status is used is to make adjustments to benefits from the coverage window. It is never attached to a claim. 4:This differs from Received only slightly. It's for additional payments on procedures already received. Most fields are blank. 5: CapClaim is used when you want to send a claim to a capitation insurance company. These are similar to Supplemental in that there will always be a duplicate claimproc for a procedure. The first claimproc tracks the copay and writeoff, has a status of CapComplete, and is never attached to a claim. The second claimproc has status of CapClaim. 6: Estimates have replaced the fields that were in the procedure table. Once a procedure is complete, the claimprocstatus will still be Estimate. An Estimate can be attached to a claim and status gets changed to NotReceived. 7: For capitation procedures that are complete. This replaces the old procedurelog.CapCoPay field. This stores the copay and writeoff amounts. The copay is only there for reference, while it is the writeoff that actually affects the balance. Never attached to a claim. If procedure is TP, then status will be CapEstimate. Only set to CapComplete if procedure is Complete. 8: For capitation procedures that are still estimates rather than complete. When procedure is completed, this can be changed to CapComplete, but never to anything else. Amount insurance actually paid. The remarks that insurance sends in the EOB about procedures. FK to claimpayment.ClaimPaymentNum(the insurance check). FK to insplan.PlanNum This is the date that is used for payment reports and tracks the payment date. Always exactly matches the date of the ClaimPayment it's attached to. See the note under Ledgers.ComputePayments. This will eventually not be used for aging. The ProcDate will instead be used. See ProcDate. Amount not covered by ins which is written off The procedure code that was sent to insurance. This is not necessarily the usual procedure code. It will already have been trimmed to 5 char if it started with "D", or it could be the alternate code. Not allowed to be blank if it is procedure. -1 if blank which indicates allowed is same as fee. This is the amount that the percentage is based on. Usually the same as the fee, unless this ins plan has lower UCR. Could also be different for ins substitutions, like posterior composites. If -1, then it might be changed during Procedure.ComputeEstimates/ClaimProc.ComputeBaseEst. But once there is a value, it is guaranteed not to be changed unless user changes it. -1 if blank. Otherwise a number between 0 and 100. The percentage that insurance pays on this procedure, as determined from insurance categories. Not user editable. -1 if blank. Otherwise a number between 0 and 100. Can only be changed by user. -1 if blank. Calculated automatically. User can not edit but can use CopayOverride instead. Opposite of InsEst, because this is the patient portion estimate. Two different uses: 1. For capitation, this automates calculation of writeoff. 2. For any other insurance, it gets deducted during calculation as shown in the edit window. Neither use directly affects patient balance. -1 if blank. Lets user override the percentAmt. This field is not updated when recalculating and is only changed by user. Set to true to not bill to this insurance plan. Set true to apply the deductible before the percentage instead of the usual way of applying it after. -1 if blank. The amount to subtract during estimating because annual benefits have maxed out. -1 if blank. The amount paid by another insurance. This amount is then subtracted from what the current insurance would pay. So, always blank for primary claims. Always has a value. Used in TP, etc. The base estimate is the ((fee or allowedAmt)-Copay) x (percentage or percentOverride). Does not include all the extras like ded, annualMax,and paidOtherIns that InsPayEst will hold in future estimating. -1 if blank. See description of CopayAmt. This lets the user set a copay that will never be overwritten by automatic calculations. Date of the procedure. Currently only used for tracking annual insurance benefits remaining. Important in Adjustments to benefits. For total claim payments, MUST be the date of the procedures to correctly figure benefits. Will eventually transition to use this field to actually calculate aging. See the note under Ledgers.ComputePayments. Date that it was changed to status received or supplemental. It is usually attached to a claimPayment at that point, but not if user forgets. This is still the date that it becomes important financial data. Only applies if Received or Supplemental. Otherwise, the date is disregarded. User may never edit. Important in audit trail.
Since we can send e-claims to multiple clearinghouses, this table keeps track of each clearinghouse. Will eventually be used for individual carriers as well if they accept Primary key. Description of this clearinghouse The path to export the X12 file to. Includes \. Set to true if this is the default clearinghouse to which you want most of your e-claims sent. A list of all payors which should have claims sent to this clearinghouse. Comma delimited with no spaces. Not necessary if IsDefault. Enum:ElectronicClaimFormat The format of the file that gets sent electronically. For every type of electronic claim format that Open Dental can create, there will be an item in this enumeration. All e-claim formats are hard coded due to complexity. 0-Not in database, but used in various places in program. 1-The American standard. HIPAA mandated. 2-Proprietary format for Renaissance. The ID of the clearinghouse. Provided by them. Usually goes on ISA08. Examples: BCBSGA or 0135WCH00(webMD) Password is usually combined with the login ID for user validation. The path that all incoming response files will be saved to. Includes \. Enum:EclaimsCommBridge One of the included hard-coded communications briges. Or none to just create the claim files without uploading. Each clearinghouse can have a hard-coded comm bridge which handles all the communications of transfering the claim files to the clearinghouse/carrier. Does not just include X12, but can include any format at all. 0-No comm bridge will be activated. The claim files will be created to the specified path, but they will not be uploaded. 1 2 3 4 5 6 7 8 If applicable, this is the name of the client program to launch. It is even used by the hard-coded comm bridges, because the user may have changed the installation directory or exe name. Each clearinghouse increments their batch numbers by one each time a claim file is sent. User never sees this number. Maxes out at 999, then loops back to 1. This field is skipped during all update and retreival except if specifically looking for this one field. Defaults to 0 for brand new clearinghouses, which causes the first batch to go out as #1. 1,2,3,or 4. The port that the modem is connected to if applicable. Always uses 9600 baud and standard settings. Will crash if port or modem not valid. A clearinghouse usually has a login ID that is used with the password in order to access the remote server. This value is not usualy used within the actual claim.
A clinic is usually a separate physical office location. If multiple clinics are sharing one database, then this is used. Patients, Operatories, Claims, and many other types of objects can be assigned to a clinic. Primary key. Used in patient,payment,claimpayment,appointment,procedurelog . . Second line of address. . 2 char in the US. Does not include any punctuation. Should be exactly 10 digits The account number for deposits. Enum:PlaceOfService Usually 0 unless a mobile clinic for instance. 0. CPT code 11 1. CPT code 12 2. CPT code 21 3. CPT code 22 4. CPT code 31 5. CPT code 33 6. CPT code ? 7. CPT code 15 8. CPT code 03 9. CPT code 26 10. CPT code 50 11. CPT code 71 12. CPT code 72
Each row is either a clock-in or a clock-out event. This table will soon be significantly changed so that each row will contain both the clock-in and the clock-out. As it is right now, it's nearly impossible to do queries that give you summary results. Primary key. FK to employee.EmployeeNum The actual time that this entry was entered. The time to display and to use in all calculations. True for ClockIn, and false for ClockOut. Enum:TimeClockStatus Home, Lunch, or Break. 0 1 2 .
Tracks all forms of communications with patients, including emails, phonecalls, postcards, etc. Primary key. FK to patient.PatNum. Date of entry Enum:CommItemType . CommItemType of 0 is reserved for later use with user defined types. 1- auto. 2- Any activity related to appointment scheduling. 3- 4- 5- 6- Note for this commlog entry. Enum:CommItemMode Phone, email, etc. 0- 1- 2 3 4 5 Enum:CommSentOrReceived Neither=0,Sent=1,Received=2. 0 1 2 FK to emailmessage.EmailMessageNum, if there is an associated email. Otherwise 0.
Keeps track of the computers in an office. The list will eventually become cluttered with the names of old computers that are no longer in service. The old rows can be safely deleted. Although the primary key is used in at least one table, this will probably be changed, and the computername will become the primary key. Primary key. Name of the computer. No longer used. Moved to printer table. Used to hold default printer for each computer
Like a rolodex for businesses that the office interacts with. Used to store pharmacies, etc. Primary key. Last name or, frequently, the entire name. First name is optional. Work phone. Fax number. FK to definition.DefNum Note for this contact.
Used in public health. Primary key, but allowed to change. Change is programmatically synchronized. Optional. Usage varies.
Insurance coverage categories. They need to look like in the manual for the American calculations to work properly. Primary key. Description of this category. Default percent for this category. -1 to skip this category and not apply a percentage. The order in which the categories are displayed. Includes hidden categories. 0-based. If true, this category will be hidden. Enum:EbenefitCategory The X12 benefit categories. Each CovCat can link to one X12 category. Default is 0 (unlinked). The X12 benefit categories. Used to link the user-defined CovCats to the corresponding X12 category. 0- Default 1- X12: 30 and 35. All ADA codes. 2- X12: 23. ADA D0000-D0999 3- X12: 24. ADA D4000 4- X12: 25. ADA D2000 5- X12: 26. ADA D3000 6- X12: 27. ADA D5900-D5999 7- X12: 36. Subcategory of restorative. 8- X12: 37. ADA range? 9- X12: 38. ADA D8000 10- X12: 39. ADA D5000-D5899 (removable), and D6200-D6900 (fixed) 11- X12: 40. ADA D7000 12- X12: 41. ADA D1000
Always attached to covcats, this describes the span of procedure codes to which the category applies. Primary key. FK to covcat.CovCatNum. Lower range of the span. Does not need to be a valid code. Upper range of the span. Does not need to be a valid code.
The info in the definition table is used by other tables extensively. Almost every table in the database links to definition. Almost all links to this table will be to a DefNum. Using the DefNum, you can find any of the other fields of interest, usually the ItemName. Make sure to look at the Defs class to see how the definitions are used. Loaded into memory ahead of time for speed. Some types of info such as operatories started out life in this table, but then got moved to their own table when more complexity was needed. Primary key. Enum:DefCat Definition Category. Go to the definition setup window in the program to see how each of these categories is used. 0- Colors to display in Account module. 1- Adjustment types. 2- Appointment confirmed types. 3- Procedure quick add list for appointments. 4- Billing types. 5- Not used. 6- Not used. 7- Fee schedule names. 8- Medical notes for quick paste. 9- No longer used 10- Payment types. 11- Procedure code categories. 12- Progress note colors. 13- Statuses for recall, unscheduled, and next appointments. 14- Service notes for quick paste. 15- Discount types. 16- Diagnosis types. 17- Colors to display in the Appointments module. 18- Image categories. 19- Quick add notes for the ApptPhoneNotes, which is getting phased out. 20- Treatment plan priority names. 21- Miscellaneous color options. 22- Colors for the graphical tooth chart. 23- Categories for the Contact list. 24- Categories for Letter Merge. 25- Types of Schedule Blockouts. 26- Categories of procedure buttons in Chart module Order that each item shows on various lists. Each category is a little different. This field is usually the common name of the item. This field can be used to store extra info about the item. Some categories include a color option. If hidden, the item will not show on any list, but can still be referenced.
A deposit slip. Contains multiple insurance and patient checks. Primary key. The date of the deposit. User editable. Usually includes name on the account and account number. Possibly the bank name as well. Total amount of the deposit. User not allowed to directly edit.
Each row is one disease that one patient has. A disease is a medical condition or allergy. Diseases are defined in the DiseaseDef table. Primary key. FK to patient.PatNum FK to diseasedef.DiseaseDefNum. The disease description is in that table. Any note about this disease that is specific to this patient.
A list of diseases that can be assigned to patients. Cannot be deleted if in use by any patients. Primary key. . The order that the diseases will show in various lists. If hidden, the disease will still show on any patient that it was previously attached to, but it will not be available for future patients.
Links documents (images) to patients. This will allow one document to be shared between multiple patients in a future version. Primary key. FK to patient.PatNum. FK to document.DocNum.
It should be called image, but the name is for historical reasons. Represents a single document in the images module. This table indicates in which patient's folder the image can be found, but the actual attaching of the image to the patient is done by the docattach table. Primary key. Description of the document. Date created. FK to definition.DefNum. Cateories for documents. FK to patient.PatNum. Patient folder that document is in.(for sharing situations later) The name of the file. Does not include any directory info. Enum:ImageType eg. document, radiograph, photo, file The type of image for images module. 0- Includes scanned documents and screenshots. 1 2 3- For instance a Word document or a spreadsheet. Not an image. True if flipped horizontally. A vertical flip would be stored as a horizontal flip plus a 180 rotation. Only allowed 0,90,180, and 270. Incomplete. An optional list of tooth numbers separated by commas. The tooth numbers will be in American format and must be processed for display. When displayed, dashes will be used for sequences of 3 or more tooth numbers.
A message that will show on certain patient statements when printing bills. Criteria must be met in order for the dunning message to show. Primary key. The actual dunning message that will go on the patient bill. FK to definition.DefNum. This is an int field, but program forces only 0,30,60,or 90. Enum:YN Set Y to only show if insurance is pending. Unknown,Yes, or No. 0 1 2
Corresponds to the electid table in the database. Never editable by users. We keep this table updated with new numbers as part of upgrades, so never edit this table as it will mess up our primary keys. Helps with entering elecronic/payor id's as well as keeping track of the specific carrier requirements. Only used by the X12 format. Primary key. aka Electronic ID. A simple string. As published. Not editable. Used when doing a search. True if medicaid. Then, the billing and treating providers will have their Medicaid ID's attached. Integers separated by commas. Each int represents a ProviderSupplementalID type that is required by this insurance. Usually only used for BCBS or other carriers that require supplemental provider id's. Even if we don't put the supplemental types in here, the user can still add them. This just helps by doing an additional check for known required types. Any comments. Usually includes enrollment requirements and descriptions of how to use the provider id's supplied by the carrier because they might call them by different names.
An outgoing email message is stored here. Always attached to a commlog entry for now. Primary key. FK to patient.PatNum Single valid email address. Bcc field will be added later. We will never allow visible cc for privacy reasons. Valid email address. Subject line. Body of the email Date and time the message was sent. Automated field.
A template email which can be used as the basis for a new email. Primary key. Default subject line. Body of the email
An employee at the dental office. Primary key. Employee's last name. First name. Middle initial or name. If hidden, the employee will not show on the list. This is just text used to quickly display the clockstatus. eg Working,Break,Lunch,Home, etc.
Most insurance plans are organized by employer. This table keeps track of the list of employers. The address fields were added at one point, but I don't know why they don't show in the program in order to edit. Nobody has noticed their absence even though it's been a few years, so for now we are just using the EmpName and not the address. Primary key. Name of the employer. . Second line of address. . 2 char in the US. . Includes any punctuation.
There is one entry in this table for each fee for a single procedurecode. So if there are 5 different fees stored for one procedurecode, then there will be five entries here. Primary key. The amount usually charged. If an amount is unknown, then the entire Fee entry is deleted from the database. The absence of a fee is sometimes shown in the user interface as a blank entry, and sometimes as 0.00. FK to procedurelog.ADACode. FK to definition.DefNum. Not used. Not used.
All 5 of the graphic tables are completely obsolete now that we have the 3D teeth.
Every user group has certain permissions. This defines a permission for a group. The absense of permission would cause that row to be deleted from this table. Primary key. Only granted permission if newer than this date. Can be Minimum (01-01-0001) to always grant permission. Can be 0 to always grant permission. Otherwise, only granted permission if item is newer than the given number of days. 1 would mean only if entered today. FK to usergroup.UserGroupNum. The user group for which this permission is granted. If not authorized, then this groupPermission will have been deleted. Enum:Permissions A hard-coded list of permissions which may be granted to usergroups. 0 1 2 3 4 5 6 7 8. Currently covers a wide variety of setup functions. 9 10 11 12 13 14 15 16 17 18 19 20. Not used anymore. 21 Not used anymore. 22 23. Includes setting procedures complete. 24. At least one user must have this permission. 25 26 27 28 29 30 31 32
There is a separate insplan in this table for each subscriber. Subscribers never share insplans, although multiple patients can have the plan assigned to them (with the one subscriber). But plans can have identical information in them as other plans. In this case, they are considered similar or identical, and some synchronization can be done. For some offices, this synchronization will be extensive, with hundreds of identical insplans. Primary key. FK to patient.PatNum. Date plan became effective. Date plan was terminated Optional Optional. Note for all plans identical to this one. Always stays in synch with other identical plans regardless of user actions. If they change it on one, it gets changed on all. FK to definition.DefNum. Name of fee schedule is stored in definition.ItemName. Release of information signature is on file. Assignment of benefits signature is on file. ""=percentage(the default),"f"=flatCopay,"c"=capitation. FK to claimform.ClaimFormNum. eg. "0" for ADA2002 0=no,1=yes. could later be extended if more alternates required Fee billed on claim should be the UCR fee for the patient's provider. FK to definition.DefNum. Not usually used. This fee schedule holds only co-pays(patient portions). Only used for Capitation or for fixed copay plans. Usually SSN, but can also be changed by user. No dashes. Not allowed to be blank. FK to employer.EmployerNum. FK to carrier.CarrierNum. FK to Definition.DefNum. Not usually used. This fee schedule holds amounts allowed by carriers. . Only used in Canada. It's a suffix to the group number. User doesn't usually put these in. Only used when automatically requesting benefits, such as with Trojan. All the benefits get stored here in text form for later reference. Specific to one plan and not synchronized because might be specific to subscriber. If blank, we might add a function to try to find any benefitNote for a similar plan. True if this is medical insurance rather than dental insurance. Specific to an individual plan and not synchronized in any way. Use to store any other info that affects coverage.
Used by dental schools. Primary key. . . eg DMD, DDS, RDH.
Used in accounting to represent a single credit or debit entry. There will always be at least 2 journal enties attached to every transaction. All transactions balance to 0. Primary key. FK to transaction.TransactionNum FK to account.AccountNum Always the same for all journal entries within one transaction. Negative numbers never allowed. Negative numbers never allowed. . A human-readable description of the splits. Used only for display purposes. Any user-defined string. Usually a check number, but can also be D for deposit, Adj, etc. FK to reconcile.ReconcileNum. 0 if not attached to a reconcile. Not allowed to alter amounts if attached.
This is a list of phrases that need to be translated. The primary key is a combination of the ClassType and the English phrase. This table is currently filled dynmically at run time, but the plan is to fill it using a tool that parses the code. A string representing the class where the translation is used. Maximum length is 25 characters. The English version of the phrase, case sensitive. As this gets more sophisticated, we will use this field to mark some phrases obsolete instead of just deleting them outright. That way, translators will still have access to them. For now, this is not used at all.
Will usually only contain translations for a single foreign language, although more are allowed. The primary key is a combination of the ClassType and the English phrase and the culture. A string representing the class where the translation is used. The English version of the phrase. Case sensitive. The specific culture name. Almost always in 5 digit format like this: en-US. The foreign translation. Remember we use Unicode-8, so this translation can be in any language, including Russian, Hebrew, and Chinese. Comments for other translators for the foreign language.
These are templates that are used to send simple letters to patients. Primary key. Description of the Letter. Text of the letter
Describes the templates for letter merges to Word. Primary key. Description of this letter. The filename of the Word template. eg MyTemplate.doc. The name of the data file. eg MyTemplate.txt. FK to definition.DefNum.
When doing a lettermerge, a data file is created with certain fields. This is a list of those fields for each lettermerge. Primary key. FK to lettermerge.LetterMergeNum. One of the preset available field names.
A list of medications, not attached to any particular patient. Not allowed to delete if in use by a patient. Not allowed to edit name once created due to possibility of damage to patient record. Primary key. Name of the medication. FK to medication.MedicationNum. If this is a generic drug, then the GenericNum will be the same as the MedicationNum. Notes.
Links medications to patients. Primary key. FK to patient.PatNum. FK to medication.MedicationNum. Medication notes specific to this patient.
Each row is a single operatory or column in the appts module. Primary key The full name to show in the column. 5 char or less. Not used much. The order that this op column will show. Changing views only hides some ops; it does not change their order. Used instead of deleting to hide an op that is no longer used. FK to provider.ProvNum. The dentist assigned to this op. If more than one dentist might be assigned to an op, then create a second op and use one for each dentist. If 0, then no dentist is assigned. FK to provider.ProvNum. The hygienist assigned to this op. If 0, then no hygienist is assigned. Set true if this is a hygiene operatory. The hygienist will then be considered the main provider for this op. FK to clinic.ClinicNum. 0 if no clinic.
These are custom fields added and managed by the user. Primary key. FK to patient.PatNum FK to patfielddef.FieldName. The full name is shown here for ease of use when running queries. But the user is only allowed to change fieldNames in the patFieldDef setup window. Any text that the user types in.
These are the definitions for the custom patient fields added and managed by the user. Primary key. The name of the field that the user will be allowed to fill in the patient info window.
One row for each patient. Includes deleted patients. Primary key. Last name. First name. Middle initial or name. Preferred name, aka nickname. Enum:PatientStatus 0 1 2 3 4 5 Enum:PatientGender 0 1 2- This is not a joke. Required by HIPAA for privacy. Enum:PatientPosition Marital status would probably be a better name for this column. 0 1 2 3 4 Age is not stored in the database. Age is always calculated as needed from birthdate. In the US, this is 9 digits, no dashes. For all other countries, any punctuation or format is allowed. . . . 2 Char in USA Postal code. Home phone. Includes any punctuation . . FK to patient.PatNum. Head of household. Single char. Shows at upper left corner of appointments. Suggested use is A,B,or C to designate creditworthiness, but it can actually be used for any purpose. . For example: Dear Mr. Smith. Not used by the program in any way. Current patient balance.(not family). If user has checked BalancesDontSubtractIns in setup, then this will not take into account insurance. Otherwise, the insurance estimate pending will have already been subtracted. May be 0. Also see the PlannedIsDone field. Otherwise it is the foreign key to appointment.AptNum. This is the appointment that will show in the Chart module and in the Planned appointment tracker. It will never show in the Appointments module. In other words, it is the suggested next appoinment rather than an appointment that has already been scheduled. FK to provider.ProvNum. The patient's primary provider. Required, although the program is robust enough to handle a missing provNum, and will use the practice default instead. FK to provider.ProvNum. Secondary provider (hygienist). Optional. FK to definition.DefNum. Fee schedule for this patient. Usually not used. If missing, the practice default fee schedule is used. If patient has insurance, then the fee schedule for the insplan is used. FK to definition.DefNum. Must have a value, or the patient will not show on some reports. Name of folder where images will be stored. Not editable for now. Address or phone note. Unlimited length in order to handle data from other programs during a conversion. Family financial urgent note. Only stored with guarantor, and shared for family. Individual patient note for Urgent medical. Individual patient note for Appointment module note. Single char for Nonstudent, Parttime, or Fulltime. Blank=Nonstudent College name. Max 15 char. Used for reference to previous programs. Optional. The Medicaid ID for this patient. Aged balance from 0 to 30 days old. Aging numbers are for entire family. Only stored with guarantor. Aged balance from 31 to 60 days old. Aging numbers are for entire family. Only stored with guarantor. Aged balance from 61 to 90 days old. Aging numbers are for entire family. Only stored with guarantor. Aged balance over 90 days old. Aging numbers are for entire family. Only stored with guarantor. Insurance Estimate for entire family. Total balance for entire family before insurance estimate. Not the same as the sum of the 4 aging balances because this can be negative. Only stored with guarantor. FK to employer.EmployerNum. Not used since version 2.8. Enum:PatientRace Race and ethnicity. Race and ethnicity for patient. Used by public health. 0 1 2 3 4 5 6 7 8 9 FK to county.CountyName, although it will not crash if key absent. FK to school.SchoolName, although it will not crash if key absent. Name of gradeschool or highschool. Enum:PatientGrade Gradelevel. Grade level used in public health. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Enum:TreatmentUrgency Used in public health screenings. For public health. Unknown, NoProblems, NeedsCarE, or Urgent. The date that the patient first visited the office. Automated. FK to clinic.ClinicNum. Can be zero if not attached to a clinic or no clinics set up. For now, an 'I' indicates that the patient has insurance. This is only used when displaying appointments. It will later be expanded. User can't edit. The Trophy bridge is inadequate. This is an attempt to make it usable for offices that have already invested in Trophy hardware. This simply indicates whether the 'done' box is checked in the chart module. Used to be handled as a -1 in the NextAptNum field, but now that field is unsigned. Set to true if patient needs to be premedicated for appointments, includes PAC, halcion, etc.
Essentially more columns in the patient table. They are stored here because these fields can contain a lot of information, and we want to try to keep the size of the patient table a bit smaller. FK to patient.PatNum. Also the primary key for this table. Always one to one relationship with patient table. A new patient might not have an entry here until needed. Only one note per family stored with guarantor. No longer used. Medical Summary Service notes Complete current Medical History Shows in the Chart module just below the graphical tooth chart.
Each row represents the linking of one insplan to one patient for current coverage. Dropping a plan will delete the entry in this table. Deleting a plan will delete the actual insplan (if no dependencies). Primary key FK to patient.PatNum. The patient who currently has the insurance. Not the same as the subscriber. FK to insplan.PlanNum. The insurance plan attached to the patient. Number like 1, 2, 3, etc. Represents primary ins, secondary ins, tertiary ins, etc. 0 is not used For informational purposes only. For now, we lose the previous feature which let us set isPending without entering a plan. Now, you have to enter the plan in order to check this box. Enum:Relat Remember that this may need to be changed in the Claim also, if already created. Relationship to subscriber for insurance. 0 1 2 3 4 5 6 7 8 An optional patient ID which will override the SSN on eclaims if present. Subscriber ID is part of the insplan.
A patient payment. Always has at least one split. Primary key.