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.
7- Patient "post-it" note on the schedule. Shows light yellow. Shows on day scheduled just like appt, as well as in prog notes, etc.
8- Patient "post-it" note completed
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.
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.
Not used.
Not used
Not used.
Not used.
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. There is usually only one or two conditions for a given AutoCodeItem.
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. There are multiple AutoCodeItems for a given AutoCode. Each Item has one ADA code.
Primary key.
FK to autocode.AutoCodeNum
Do not use
FK to procedurecode.CodeNum
Primary key
Name of AutoNote
A list of all the controles to use. Sequence of numbers separated by commas. Numbers are foreign keys.
Primary key
'Descript' is the name of the custom control
The type of control such as 'TextBox' or 'ComboBox'
Is the text for the label the user wants
The preface text
If the control is a multi line text box then store the text here
If the control is a combo box then the user puts the the selection options for the combo box here
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, ProcCode(- 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.
Do not use
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 Deductible.
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 using QuantityQualifier.
FK to procedurecode.CodeNum. Typical uses include fluoride, sealants, etc. If a specific code is used here, then the CovCat is completely ignored.
There are so many extra fields required for Canadian claims that we made a new table for them. Each row in this table will have a 1:1 relationship with a claim.
FK to claim.ClaimNum. Also the primary key.
A08. Any combination of E(email), C(correspondence), M(models), X(x-rays), and I(images). So up to 5 char. Gets converted to a single char A-Z for e-claims.
B05. Optional. The 9-digit CDA number of the referring provider, or identifier of referring party up to 10 characters in length.
B06. A number 0(none) through 13.
E18. Y, N, or X(yes, but details unknown). User must enter without default.
F18. Y, N, or X(not a lower denture, crown, or bridge).
F19. Mandatory if F18 is N.
F21. If crown, not required. If denture or bridge, required if F18 is N. Single digit number code, 0-6. We added type 7, which is crown.
F15. Y, N, or X(not an upper denture, crown, or bridge).
F04. Mandatory if F15 is N.
F20. If crown, not required. If denture or bridge, required if F15 is N. Single digit number code, 0-6. We added type 7, which is crown.
C09. A single digit 1-4. 0 is not acceptable for e-claims.
C10. Can't initially copy from patient.SchoolName because not allowed to default. Must ask patient each time.
F01. Mandatory. Single digit 1-4.
Represents one extraction that goes out on a Canadian claim. This is needed because they have stricter requirements in this area, and they also need date of extraction if prosthesis. It also provides a permanent record of what was sent.
Primary key.
FK to claim.ClaimNum.
Always 1-32 or A-T. 1 or 2 char. Get's converted to international tooth numbers just before display.
Will be min val if no date.
Primary key.
This will also be the folder name
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 in USA. 6 digits in Canada. I've seen an ID this long before: "LA-DHH-MEDICAID". The user interface currently limits length to 20, although db limits length to 255. X12 requires length between 2 and 80.
Do not send electronically. It's just a default; you can still send electronically.
Canada: True if a CDAnet carrier. This has significant implications: 1. It can be filtered for in the list of carriers. 2. An ElectID is required. 3. The ElectID can never be used by another carrier. 4. If the carrier is attached to any etrans, then the ElectID cannot be changed (and, of course, the carrier cannot be deleted or combined).
Canada: True if Provincial Medical Plan. We might need to make this a plan field instead.
The version of CDAnet supported. Either 2, 3, or 4.
FK to canadiannetwork.CanadianNetworkNum. Only used in Canada.
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, S=Sent, R=Received. A(adj) is no longer used. P(prob sent) 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.
FK to claimform.ClaimFormNum. 0 if not assigned to use the claimform for the insplan.
Enum:EtransType to define a specific version of an e-claim. Only used for medical claims right now.
The _CA of some types should get stripped off when displaying to users.
0 X12-837
1 claim
2 Canada. Type 01
3 Renaissance
4 Canada. Type 11
5 Canada. Type 21
6 Canada. Type 08
7 Canada. Type 18
8 Canada. Type 02
9 Canada. Type 03
10 Canada. Type 04
11 Canada. Type 05
12 Canada. Type 06
13 Canada. Type 07
14 Canada. Type 12
15 Canada. Type 13
16 Canada. Type 23
17 Canada. Type 14
18 Canada. Type 24
19 Canada. Type 16
20 Canada. Type 15
21 Ack from clearinghouse. X12-997.
22 X12-277. Unsolicited claim status notification.
23 Text report from clearinghouse in human readable format.
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##. Forms 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, ADA2006=OD8, 1500=OD9
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. It is never changed automatically except to sometimes set it to -1. During Procedure.ComputeEstimates/ClaimProc.ComputeBaseEst, an allowed amount is calculated on the fly, but is no longer saved here.
-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 allowedOverride)-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.
Assigned when claim is created as a way to order the procs showing on a claim. Really only used in Canadian claims for now as F07.
Primary key.
FK to claim.ClaimNum.
Descriptive abbreviation to help place field on form (Ex: "FL55" for field 55).
Value Code.
Value Code Amount.
Order of Value Code
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. \ is now optional.
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.
3-CDAnet format version 4.
Sender ID Qualifier. Usually ZZ, sometimes 30. Seven other values are allowed as specified in X12 document, but probably never used.
Used in ISA06, GS02, 1000A NM1, and 1000A PER. If blank, then 810624427 is used to indicate Open Dental.
Receiver ID Qualifier. Usually ZZ, sometimes 30. Seven other values are allowed as specified in X12 document, but probably never used.
Receiver ID. Also used in GS03. Provided by clearinghouse. Examples: BCBSGA or 0135WCH00(webMD)
"P" for Production or "T" for Test.
Password is usually combined with the login ID for user validation.
The path that all incoming response files will be saved to. \ is now optional.
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
9 Canada
10
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.
Used in 1000A NM1 and 1000A PER. But if SenderTIN is blank, then OPEN DENTAL SOFTWARE is used instead.
Used in 1000A PER. But if SenderTIN is blank, then 8776861248 is used instead. 10 digit phone is required by WebMD and is universally assumed, so for now, this must be either blank or 10 digits.
Usually the same as ISA08, but at least one clearinghouse uses a different number here.
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 and time of entry
FK to definition.DefNum. This will be 0 if IsStatementSent. Used to be an enumeration in previous versions.
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=neither, 1=sent, 2=received.
0
1
2
FK to user.UserNum.
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
Enables preference specification for individual computers on a customer network.
Primary key.
The human-readable name of the computer on the network (not the IP address).
Set to true if the tooth chart is to use a hardware accelerated OpenGL window when available. Set to false to use software rendering when available. Of course, the final pixel format on the customer machine depends on the list of available formats. Best match pixel format is always used. This option only applies if GraphicsSimple is set to false.
Set to true to use the low-quality 2D tooth chart in the chart module. Set to false to use an 3D OpenGL based tooth chart in the chart module. This option is a work-around for machines where the OpenGL implementation on the local graphics hardware is buggy or unavailable (i.e. MONO).
Indicates the type of Suni sensor connected to the local computer (if any). This can be a value of A, B, C, or D.
Indicates wether or not the Suni sensor uses binned operation.
Indicates which Suni box port to connect with. There are 2 ports on a box (ports 0 and 1).
Indicates the exposure level to use when capturing from a Suni sensor. Values can be 1 through 7.
Indicates if the user prefers double-buffered 3D tooth-chart (where applicable).
Indicates the current pixel format by number which the user prefers.
The path of the A-Z folder for the specified computer. Overrides the officewide default. Used when multiple locations are on a single virtual database and they each want to look to the local data folder for images.
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
27- Types of commlog entries.
28- Categories of Supplies
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.
Allows customization of which fields display in various lists and grids. For now, the only grid is ProgressNotes. Will also eventually let users set column widths and translate titles. For now, the selections are the same for all computers.
Primary key.
This is the internal name that OD uses to identify the field within this category. This will be the default description if the user doesn't specify an alternate.
Order to display in the grid or list. Every entry must have a unique itemorder.
Optional alternate description to display for field. Can be in another language.
For grid columns, this lets user override the column width. Especially useful for foreign languages.
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. Categories 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.
4- For xray mount sets.
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.
True if the signature is in Topaz format rather than OD format.
The encrypted and bound signature in base64 format. The signature is bound to the byte sequence of the original image.
Crop rectangle X in original image pixel coordinates. May be negative.
Crop rectangle Y in original image pixel coordinates. May be negative.
Crop rectangle Width in original image pixel coordinates. May be zero if no cropping. May be greater than original image width.
Crop rectangle Height in original image pixel coordinates. May be zero if no cropping. May be greater than original image height.
The lower value of the "windowing" (contrast/brightness) for radiographs. Default is 0. Max is 255.
The upper value of the "windowing" (contrast/brightness) for radiographs. Default is 0(no windowing). Max is 255.
FK to mountitem.MountItemNum. If set to 0, then no mount item is associated with this document.
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.
Keeps track of one file attached to an email. Multiple files can be attached to an email using this method.
Primary key.
FK to emailmessage.EmailMessageNum
The name of the file that shows on the email. For example: tooth2.jpg.
The actual file is stored in the A-Z folder in EmailAttachments. This field stores the name of the file. The files are named automatically based on Date/time along with a random number. This ensures that they will be sequential as well as unique.
An outgoing email message is stored here.
Primary key.
FK to patient.PatNum
Single valid email address. Bcc field might be added later, although it won't be very useful. 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.
0=neither, 1=sent, 2=received.
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.
One electronic transaction. Typically, one claim or response. Will later be expanded to include many other types of transactions with clearinghouses, such as eligibility, reports, etc. Also stores printing of paper claims. Sometimes stores a copy of what was sent.
Primary key.
The date and time of the transaction.
FK to clearinghouse.ClearinghouseNum . Can be 0 if no clearinghouse was involved.
Enum:EtransType
The _CA of some types should get stripped off when displaying to users.
0 X12-837
1 claim
2 Canada. Type 01
3 Renaissance
4 Canada. Type 11
5 Canada. Type 21
6 Canada. Type 08
7 Canada. Type 18
8 Canada. Type 02
9 Canada. Type 03
10 Canada. Type 04
11 Canada. Type 05
12 Canada. Type 06
13 Canada. Type 07
14 Canada. Type 12
15 Canada. Type 13
16 Canada. Type 23
17 Canada. Type 14
18 Canada. Type 24
19 Canada. Type 16
20 Canada. Type 15
21 Ack from clearinghouse. X12-997.
22 X12-277. Unsolicited claim status notification.
23 Text report from clearinghouse in human readable format.
FK to claim.ClaimNum if a claim. Otherwise 0. Warning. Original claim might have been deleted. But if Canadian claim was successfully sent, then deletion will be blocked.
For Canada. Unique for every transaction sent. Increments by one until 999999, then resets to 1.
For Canada. Separate counter for each carrier. Increments by one until 99999, then resets to 1.
For Canada. If this claim includes secondary, then this is the counter for the secondary carrier.
FK to carrier.CarrierNum.
FK to carrier.CarrierNum Only used if secondary insurance info is provided on a claim. Necessary for Canada.
This is useful in case the original claim has been deleted. Now, we can still tell who the patient was.
Whether outgoing or incoming, this field contains the actual text of the message. When there is a batch, this field will contain the text of the entire batch. Other claims will be mixed in. The same text will be duplicated in the MessageText fields on the other claims.
Maxes out at 999, then loops back to 1. This is not a good key, but is a restriction of (canadian?). So dates must also be used to isolate the correct BatchNumber key. Specific to one clearinghouse. Only used with e-claims. Claim will have BatchNumber, and 997 will have matching BatchNumber. (In X12 lingo, it's a functional group number)
A=Accepted, R=Rejected, blank if not able to parse. More options will be added later. The incoming 997 sets this flag automatically. To find the 997, look for a matching BatchNumber with a similar date, since both the claims and the 997 will both have the same batch number. The 997 does not have this flag set on itself.
For sent e-claims, within each batch (functional group), each carrier gets it's own transaction set. Since 997s acknowledge transaction sets rather than batches, we need to keep track of which transaction set each claim is part of as well as which batch it's part of. This field can't be set as part of 997, because one 997 refers to multiple trans sets.
Typical uses include indicating that report was printed, claim was resent, reason for rejection, etc.
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.
Do not use.
FK to definition.DefNum.
Not used.
Not used.
FK to procedurecode.CodeNum.
As an alternative to storing files in the os file system, they may be stored here, in the database.
Primary key.
longblob
longblob
One form or questionnaire filled out by a patient. Each patient can have multiple forms.
Primary key.
FK to patient.PatNum.
The date and time that this questionnaire was filled out.
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
33
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. In Canada, this is called the Plan Number.
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),"p"=ppo_percentage,"f"=flatCopay,"c"=capitation.
FK to claimform.ClaimFormNum. eg. "1" for ADA2002. For ADA2006, it varies by office.
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 plan number (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.
Enum:InsFilingCode Only used for e-claims. Should become obsolete when PlanID implemented by HIPAA.
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Canadian e-claim field. D11 and E07. Mandatory for Dentaide. Value must be greater than 0. Not used for all others. 2 digit.
If checked, the units Qty will show the base units assigned to a procedure on the claim form.
Apply deductible before percentage when calculating estimates.
Was used by dental schools. Obsolete.
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.
A lab case.
Primary key.
FK to patient.PatNum.
FK to laboratory.LaboratoryNum. The lab that the case gets sent to.
FK to appointment.AptNum. This is how a lab case is attached to a scheduled appointment. 1:1 relationship for now. Only one labcase per appointment, and (obviously) only one appointment per labcase. Labcase can exist without being attached to any appointments at all, making this zero.
FK to appointment.AptNum. This is how a lab case is attached to a planned appointment in addition to the scheduled appointment.
The due date that is put on the labslip. NOT when you really need the labcase back, which is usually a day or two later and is the date of the appointment this case is attached to.
When this lab case was created. User can edit.
Time that it actually went out to the lab.
Date/time received back from the lab. If this is filled, then the case is considered received.
Date/time that quality was checked. It is now completely ready for the patient.
FK to provider.ProvNum.
The Rx for this labcase.
A dental laboratory. Will be attached to lab cases.
Primary key.
Description of lab.
Freeform text includes punctuation.
Any notes. No practical limit to amount of text.
Not used yet. The text base64 representation of the background scanned labslip. Will be converted to an image at the last minute as needed. Limit of image size will be about 16 MB. Typical image size will be about 200 KB.
The amount of time it takes for a lab case to be processed at the lab. Used to compute due dates.
Primary key.
FK to laboratory.LaboratoryNum. The lab that this item is attached to.
The description of the service that the lab is performing.
The number of days that the lab publishes as the turnaround time for the service.
The actual number of days. Might be longer than DaysPublished due to travel time. This is what the actual calculations will be done on.
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.
No longer used.
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.
A mount shows in the images module just like other images in the tree. But it is just a container for images within it rather than an actual image itself.
Primary key.
FK to patient.PatNum
FK to definition.DefNum. Categories for documents.
The date at which the mount itself was created. Has no bearing on the creation date of the images the mount houses.
Used to provide a document description in the image module tree-view.
Enum:ImageType This is so that an image can be properly associated with the mount in the image module tree-view.
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.
4- For xray mount sets.
To allow the user to enter specific information regarding the exam and tooth numbers, as well as points on interest in the xray images.
The static width of the mount, in pixels.
The static height of the mount, in pixels.
THIS TABLE IS NOT BEING USED. These can be freely deleted, renamed, moved, etc. without affecting any patient info. mountitemdef
Primary key.
.
The order that the mount defs will show in various lists.
Set to true if this is just xrays. If true, this prevents image from being scaled to fit inside the mount. If false (composite photographs for example) then the images will be scaled to fit inside the mount. Later, the basic appearance or background color might be set based on this flag as well.
The width of the mount, in pixels. For radiograph mounts, this could be very large. It must be large enough for the radiographs to fit in the mount without scaling. For photos, it should also be large so that the scaling won't be too noticeable. Shrinking to view or print will always produce nicer results than enlarging to view or print.
Height of the mount in pixels.
These are always attached to a mount and are constant. Should not be deleted, but rather updated if geometry changes.
Primary key.
FK to mount.MountNum.
The x position, in pixels, of the item on the mount.
The y position, in pixels, of the item on the mount.
The ordinal position of the item on the mount.
The scaled or unscaled width of the mount item in pixels.
The scaled or unscaled height of the mount item in pixels.
THIS TABLE IS NOT BEING USED. These are always attached to mountdefs. Can be deleted without any problems.
Primary key.
FK to mountdef.MountDefNum.
The x position, in pixels, of the item on the mount.
The y position, in pixels, of the item on the mount.
Ignored if mount IsRadiograph. For other mounts, the image will be scaled to fit within this space. Any cropping, rotating, etc, will all be defined in the original image itself.
Ignored if mount IsRadiograph. For other mounts, the image will be scaled to fit within this space. Any cropping, rotating, etc, will all be defined in the original image itself.
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. For Canadian claims, it must be ANANAN. No validation gets done except there.
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. The database maintenance tool ensures that every patient always has this number set, so the program no longer has to handle 0.
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.
Obsolete. See the toothinitial table.
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.
Only used in hospitals.
Enum:ContactMethod
0
1
2
3
4
5
6
7
Enum:ContactMethod
0
1
2
3
4
5
6
7
Enum:ContactMethod
0
1
2
3
4
5
6
7
Only the time portion of the TimeSpan is used.
We do not use this, but some users do, so here it is. 0=none. Otherwise, 1-7 for day.
The primary language of the patient. Typically en, fr, es, or similar. We might later also allow cultures and user-defined languages.
Used in hospitals. It can be before the first visit date. It typically gets set automatically by the hospital system.
Includes any punctuation. For example, Mr., Mrs., Miss, Dr., etc. There is no selection mechanism yet for user; they must simply type it in.
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.
Credit Card Number. It is a field that must be turned on to be visible, so it usually isn't.
Credit Card expiration date. Only month and year are used, and the day is usually just 1. This field is usually hidden to the user.
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.
FK to definition.DefNum. This will be 0 if this is an income transfer to another provider.
The date the the payment displays on the patient account.
Amount of the payment. Must equal the sum of the splits.
Check number is optional.
Bank-branch for checks.
Any admin note. Not for patient to see.
Set to true to indicate that a payment is split. Just makes a few functions easier. Might be eliminated.
FK to patient.PatNum. The patient where the payment entry will show. But only the splits affect account balances. This is 0 if the 'payment' is actually an income transfer to another provider.
FK to clinic.ClinicNum. Can be 0. Copied from patient.ClinicNum when creating payment, but user can override. Not used in provider income transfers.
The date that this payment was entered. Not user editable.
FK to deposit.DepositNum. 0 if not attached to any deposits. Cash does not usually get attached to a deposit; only checks.
Used to view employee timecards. Timecard entries are not linked to a pay period. Instead, payperiods are setup, and the user can only view specific pay periods. So it feels like they are linked, but it's date based.
Primary key.
The first day of the payperiod
The last day of the payperiod.
The date that paychecks will be dated. A few days after the dateStop. Optional.
Each row represents one signed agreement to make payments.
Primary key
FK to patient.PatNum. The patient who had the treatment done.
FK to patient.PatNum. The person responsible for the payments. Does not need to be in the same family as the patient. Will be 0 if planNum has a value.
Date that the payment plan will display in the account.
Annual percentage rate. eg 18. This does not take into consideration any late payments, but only the percentage used to calculate the amortization schedule.
Generally used to archive the terms when the amortization schedule is created.
Will be 0 if standard payment plan. But if this is being used to track expected insurance payments, then this will be the foreign key to insplan.PlanNum and Guarantor will be 0.
One of the dated charges attached to a payment plan. This has nothing to do with payments, but rather just causes the amount due to increase on the date of the charge. The amount of the charge is the sum of the principal and the interest.
Primary key.
FK to payplan.PayPlanNum.
FK to patient.PatNum. The guarantor account that each charge will affect.
FK to patient.PatNum. The patient account that the principal gets removed from.
The date that the charge will show on the patient account. Any charge with a future date will not show on the account yet and will not affect the balance.
The principal portion of this payment.
The interest portion of this payment.
Any note about this particular payment plan charge
The ProvNum will be assigned according to what the patient owes. This same provnum is used to show amount due in guarantor. Payments applied should be to this provnum.
Always attached to a payment. Always affects exactly one patient account and one provider.
Primary key.
Amount of split.
FK to patient.PatNum.
Procedure date. This is the date that shows on the account. Frequently the same as the date of the payment, but not necessarily. Not when the payment was made. This is what the aging will be based on in a future version.
FK to payment.PayNum. Every paysplit must be linked to a payment.
No longer used.
No longer used
FK to provider.ProvNum.
FK to payplan.PayPlanNum. 0 if not attached to a payplan.
Date always in perfect synch with Payment date.
FK to procedurelog.ProcNum. 0 if not attached to a procedure.
Date this paysplit was created. User not allowed to edit.
One perio exam for one patient on one date. Has lots of periomeasures attached to it.
Primary key.
FK to patient.PatNum.
.
FK to provider.ProvNum.
One row can hold up to six measurements for one tooth, all of the same type. Always attached to a perioexam.
Primary key.
FK to perioexam.PerioExamNum.
Enum:PerioSequenceType eg probing, mobility, recession, etc.
In perio, the type of measurements for a given row.
0
1
2-AKA recession.
3-MucoGingivalJunction- the division between attached and unattached mucosa.
4
5
6
7. But this type is never saved to the db. It is always calculated on the fly.
Valid values are 1-32. Every measurement must be associated with a tooth.
This is used when the measurement does not apply to a surface(mobility and skiptooth). Valid values for all surfaces are 0 through 19, or -1 to represent no measurement taken.
.
.
.
.
.
.
Primary key.
FK to patient.PatNum.
The text of the popup.
If true, then the popup won't ever automatically show.
Stores small bits of data for a wide variety of purposes. Any data that's too small to warrant its own table will usually end up here.
Primary key.
The stored value.
One printer selection for one situation for one computer.
Primary key.
FK to computer.ComputerNum. This will be changed some day to refer to the computername, because it would make more sense as a key than a cryptic number.
Enum:PrintSituation One of about 10 different situations where printing takes place. If no printer object exists for a situation, then a default is used and a prompt is displayed.
0- Covers any printing situation not listed separately.
TP and perio
The name of the printer as set from the specified computer.
If true, then user will be prompted for printer. Otherwise, print directly with little user interaction.
The 'buttons' to show in the Chart module. They must have items attached in order to do anything.
Primary key
The text to show on the button.
Order that they will show in the Chart module.
FK to definition.DefNum.
If no image, then the blob will be an empty string. In this case, the bitmap will be null when loaded from the database.
Attached to procbuttons. These tell the program what to do when a user clicks on a button. There are two types: proccodes or autocodes.
Primary key.
FK to procbutton.ProcButtonNum.
Do not use.
FK to autocode.AutoCodeNum. 0 if this is a procedure code.
FK to procedurecode.CodeNum. 0 if this is an autocode.
Stores the default note and time increments for one procedure code for one provider. That way, an unlimited number of providers can each have different notes and times. These notes and times override the defaults which are part of the procedurecode table. So, for single provider offices, there will be no change to the current interface.
Primary Key.
FK to procedurecode.CodeNum.
FK to provider.ProvNum.
The note.
X's and /'s describe Dr's time and assistant's time in the same increments as the user has set.
A list setup ahead of time with all the procedure codes used by the office. Every procedurelog entry which is attached to a patient is also linked to this table.
Primary Key. This happened in version 4.8.7.
Was Primary key, but now CodeNum is primary key. Can hold dental codes, medical codes, custom codes, etc.
The main description.
Abbreviated description.
X's and /'s describe Dr's time and assistant's time in the same increments as the user has set.
FK to definition.DefNum. The category that this code will be found under in the search window. Has nothing to do with insurance categories.
Enum:TreatmentArea
Used in procedurecode setup to specify the treatment area for a procedure. This determines what fields are available when editing an appointment.
0-never used
1
2
3
4
5
6
7
No longer used. Extraction paint type is used instead to show missing teeth.
Triggers recall in 6 months or as defined.
If true, do not usually bill this procedure to insurance.
True if Crown,Bridge,Denture, or RPD. Forces user to enter Initial or Replacement and Date.
The default procedure note to copy when marking complete.
Identifies hygiene procedures so that the correct provider can be selected.
No longer used.
For Medicaid. There may be more later.
FK to procedurecode.ProcCode. The actual medical code that is being referenced must be setup first. Anytime a procedure it added, this medical code will also be added to that procedure. The user can change it in procedurelog.
Used by some offices even though no user interface built yet. SalesTaxPercentage has been added to the preference table to store the amount of sales tax to apply as an adjustment attached to a procedurelog entry.
Enum:ToothPaintingType
Replaces the graphic type table in the database for the new 3D tooth chart. We cannot yet do veneers.
0
1
2
3
4
5
6
7
8
9
10
11
12
13
If set to anything but 0, then this will override the graphic color for all procedures of this code, regardless of the status.
When creating treatment plans, this description will be used instead of the technical description.
Only used in Canada. Set to true if this procedure code is only used as an adjunct to track the lab fee.
This is true if this procedure code existed before ADA code distribution changed at version 4.8, false otherwise.
Support for Base Units for a Code (like anesthesia)
FK to procedurecode.ProcCode. Used for posterior composites because insurance substitutes the amalgam code when figuring the coverage.
Enum:SubstitutionCondition Used so that posterior composites only substitute if tooth is molar. Ins usually pays for premolar composites.
Used for insurance substitutions conditions of procedurecodes. Mostly for posterior composites.
0
1
2
Database table is procedurelog. A procedure for a patient. Can be treatment planned or completed. Once it's completed, it gets tracked more closely be the security portion of the program. A procedure can NEVER be deleted. Status can just be changed to "deleted".
Primary key.
FK to patient.PatNum
FK to appointment.AptNum. Only allowed to attach proc to one appt(not counting planned appt)
No longer used.
Procedure date/time that will show in the account as the date performed. If just treatment planned, the date can be the date it was tp'd, or the date can be min val if we don't care.
Procedure fee.
Surfaces, or use "UL" etc for quadrant, "2" etc for sextant, "U","L" for arches.
May be blank, otherwise 1-32, 51-82, A-T, or AS-TS, 1 or 2 char.
May be blank, otherwise is series of toothnumbers separated by commas.
FK to definition.DefNum, which contains the text of the priority.
Enum:ProcStat TP=1,Complete=2,Existing Cur Prov=3,Existing Other Prov=4,Referred=5,Deleted=6.
Procedure Status.
1- Treatment Plan.
2- Complete.
3- Existing Current Provider.
4- Existing Other Provider.
5- Referred Out.
6- Deleted.
FK to provider.ProvNum.
FK to definition.DefNum, which contains text of the Diagnosis.
FK to appointment.AptNum. Was called NextAptNum in older versions. Allows this procedure to be attached to a Planned appointment as well as a standard appointment.
Enum:PlaceOfService Only used in Public Health. Zero(Office) until procedure set complete. Then it's set to the value of the DefaultProcedurePlaceService preference.
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
Single char. Blank=no, or Initial, or Replacement.
For a prosthesis Replacement, this is the original date.
This note will go on e-claim. For By Report, prep dates, or initial endo date.
This is the date this procedure was entered or set complete. If not status C, then the value is ignored, so it might be minValue 0001-01-01 or any other date. It gets updated when set complete. User never allowed to edit. This will be enhanced later.
FK to clinic.ClinicNum. 0 if no clinic.
FK to procedurecode.ProcCode. Optional.
Simple text for ICD-9 code. Gets sent with medical claims.
Set true if this medical diagnostic code is the principal diagnosis for the visit. If no principal diagnosis is marked for any procedures on a medical e-claim, then it won't be allowed to be sent. If more than one is marked, then it will just use one at random.
FK to procedurelog.ProcNum. Only used in Canada. If not zero, then this proc is a lab fee and this indicates to which actual procedure the lab fee is attached. For ordinary use, they are treated like two separate procedures. It's only for insurance claims that we need to know which lab fee belongs to which procedure. For now, we limit one fee attached to one procedure.
FK to definition.DefNum. Lets some users track charges for certain types of reports. For example, a Medicaid billing type could be assigned to a procedure, flagging it for inclusion in a report mandated by goverment. Would be more useful if it was automated to flow down based on insurance plan type, but that can be added later. Not visible if prefs.EasyHideMedicaid is true.
FK to definition.DefNum. Same as BillingTypeOne, but used when there is a secondary billing type to account for.
FK to procedurecode.CodeNum
Modifier for certain CPT codes. Not used yet.
Modifier for certain CPT codes. Not used yet.
Modifier for certain CPT codes. Not used yet.
Modifier for certain CPT codes. Not used yet.
Revenue code for medical billing. Not used yet. Only used on UB92 claimforms.
Unit support for things like anesthesia billing and such.-dt
For certain CPT codes.
Base units used for some billing codes.
Start time in military
Stop time in military
The date that the procedure was originally treatment planned. Does not change when marked complete.
A procedure note for one procedure. User does not have any direct control over this table at all. It's handled automatically. When user "edits" a procedure note, the program actually just adds another note. No note can EVER be edited or deleted.
Primary key.
FK to patient.PatNum
FK to procedurelog.ProcNum
The server time that this note was entered.
FK to userod.UserNum.
The actual note.
There are two kinds of signatures. Topaz signatures use hardware manufactured by that company, and the signature is created by their library. OD signatures work exactly the same way, but are only for on-screen signing.
The encrypted signature. A signature starts as a collection of vectors. The Topaz .sig file format is proprietary. The OD signature format looks like this: 45,68;48,70;49,72;0,0;55,88;etc. It's simply a sequence of points, separated by semicolons. 0,0 represents pen up. Then, a hash is created from the Note, concatenated directly with the userNum. For example, "This is a note3" gets turned into a hash of 2849283940385391 (16 bytes). The hash is used to encrypt the signature data string using symmetric encryption. Therefore, the actual signature cannot be retrieved from the database by ordinary means. Also, the signature info cannot even be retrieved by Open Dental at all unless it supplies the same hash as before, proving that the data has not changed since signed. If OD supplies the correct hash, then it will be able to extract the sequence of vectors which it will then use to display the signature. The OD sigs are not compressed, and the Topaz sigs are. But there is very little difference in their sizes. It would be very rare for a signature to be larger than 1000 bytes.
These are copies of procedures that are attached to treatment plans.
Primary key.
FK to treatplan.TreatPlanNum. The treatment plan to which this proc is attached.
FK to patient.PatNum.
FK to procedurelog.ProcNum. It is very common for the referenced procedure to be missing. This procNum is only here to compare and test the existence of the referenced procedure. If present, it will check to see whether the procedure is still status TP.
The order of this proc within its tp. This is set when the tp is first created and can't be changed. Drastically simplifies loading the tp.
FK to definition.DefNum which contains the text of the priority.
A simple string displaying the tooth number. If international tooth numbers are used, then this will be in international format already.
Tooth surfaces or area.
Not a foreign key. Simply display text. Can be changed by user at any time.
Description is originally copied from procedurecode.Descript, but user can change it.
The fee charged to the patient. Never gets automatically updated.
The amount primary insurance is expected to pay. Never gets automatically updated.
The amount secondary insurance is expected to pay. Never gets automatically updated.
The amount the patient is expected to pay. Never gets automatically updated.
The amount of discount. Currently only used for PPOs.
Each row is a bridge to an outside program, frequently an imaging program. Most of the bridges are hard coded, and simply need to be enabled. But user can also add their own custom bridge.
Primary key.
Unique name for built-in program bridges. Not user-editable.
Description that shows.
True if enabled.
The path of the executable to run or file to open.
Some programs will accept command line arguments.
Notes about this program link. Peculiarities, etc.
Some program links (bridges), have properties that need to be set. The property names are always hard coded. User can change the value. The property is usually retrieved based on its name.
Primary key.
FK to program.ProgramNum
The description or prompt for this property.
The value.
A provider is usually a dentist or a hygienist. But a provider might also be a denturist, a dental student, or a dental hygiene student. A provider might also be a 'dummy', used only for billing purposes or for notes in the Appointments module. There is no limit to the number of providers that can be added.
Primary key.
Abbreviation. There was a limit of 5 char before version 5.4. The new limit is 255 char. This will allow more elegant solutions to various problems. Providers will no longer be referred to by FName and LName. Abbr is used as a human readable primary key.
Order that provider will show in lists.
Last name.
First name.
Middle inital or name.
eg. DMD or DDS. Was 'title' in previous versions.
FK to Definition.DefNum.
Enum:DentalSpecialty
0
1
2
3
4
5
6
7
8
9
10
11
12
13
or TIN. No punctuation
can include punctuation
.
True if hygienist.
Color that shows in appointments
If true, provider will not show on any lists
True if the SSN field is actually a Tax ID Num
No longer used since each state assigns a different ID. Use the providerident instead which allows you to assign a different BCBS ID for each Payor ID.
Signature on file.
.
Color that shows in appointments as outline when highlighted.
FK to schoolclass.SchoolClassNum Used in dental schools. Each student is a provider. This keeps track of which class they are in.
Used for Canadian claims right now as CDA number. Will be required in US within a year. Goes out on e-claims if available.
Canadian field required for e-claims. Assigned by CDA. It's OK to have multiple providers with the same OfficeNum. Max length should be 4.
Some insurance companies require special provider ID #s, and this table holds them.
Primary key.
FK to provider.ProvNum. An ID only applies to one provider.
FK to carrier.ElectID aka Electronic ID. An ID only applies to one insurance carrier.
Enum:ProviderSupplementalID
Used when submitting e-claims to some carriers who require extra provider identifiers. Usage varies by company. Only used as needed.
0
1
2
3
The number assigned by the ins carrier.
Each row is one Question for one patient. If a patient has never filled out a questionnaire, then they will have no rows in this table.
Primary key.
FK to patient.PatNum
The order that this question shows in the list.
The original question.
The answer to the question in text form.
FK to formpat.FormPatNum
Each row represents one question on the medical history questionnaire. Later, other questionnaires will be allowed, but for now, all questions are on one questionnaire for the patient. This table has no dependencies, since the question is copied when added to a patient record. Any row can be freely deleted or altered without any problems.
Primary key.
The question as presented to the patient.
The order that the Questions will show.
Enum:QuestionType
0=FreeformText, 1=YesNoUnknown. Allows for later adding other types, 3=picklist, 4, etc
0
1
Quick paste categories are used by the quick paste notes feature.
Primary key.
.
The order of this category within the list. 0-based.
Enum:QuickPasteType Each Category can be set to be the default category for multiple types of notes. Stored as integers separated by commas.
Used by QuickPasteCat to determine which category to default to when opening.
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Primary key.
FK to quickpastecat.QuickPasteCatNum. Keeps track of which category this note is in.
The order of this note within it's category. 0-based.
The actual note. Can be multiple lines and possibly very long.
The abbreviation which will automatically substitute when preceded by a ?.
Max one per patient. A patient can only have one recall date set for each type (there is currently only one type). The recall table stores a few dates that must be kept synchronized with other information in the database. This is difficult. Anytime one of the following items changes, things need to be synchronized: procedurecode.SetRecall, any procedurelog change for a patient (procs added, deleted, completed, status changed, date changed, etc), patient status changed. There are expected to be a few bugs in the synchronization logic, so anytime a patient's recall is opened, it will also update.
During synchronization, the program will frequently alter DateDueCalc, DateDue, and DatePrevious based on trigger procs. The system will also add and delete recalls as necessary. But it will not delete a recall unless all values are default and there is no useful information. When a user tries to delete a recall, they will only be successful if the trigger conditions do not apply. Otherwise, they will have to disable the recall instead.
Primary key.
FK to patient.PatNum.
Not editable. The calculated date due. Generated by the program and subject to change anytime the conditions change. It can be blank (0001-01-01) if no appropriate triggers.
This is the date that is actually used when doing reports for recall. It will usually be the same as DateDueCalc unless user has changed it. System will only update this field if it is the same as DateDueCalc. Otherwise, it will be left alone. Gets cleared along with DateDueCalc when resetting recall. When setting disabled, this field will also be cleared. This is the field to use if converting from another software.
Not editable. Previous date that procedures were done to trigger this recall. It is calculated and enforced automatically. If you want to affect this date, add a procedure to the chart with a status of C, EC, or EO.
The interval between recalls. The Interval struct combines years, months, weeks, and days into a single integer value.
FK to Definition.DefNum, or 0 for none.
An administrative note for staff use.
If true, this recall type will be disabled (there's only one type right now). This is usually used rather than deleting the recall type from the patient because the program must enforce the trigger conditions for all patients.
Used in the Accounting section. Each row represents one reconcile. Transactions will be attached to it.
Primary key.
FK to account.AccountNum
User enters starting balance here.
User enters ending balance here.
The date that the reconcile was performed.
If StartingBal + sum of entries selected = EndingBal, then user can lock. Unlock requires special permission, which nobody will have by default.
Attaches a referral to a patient.
Primary key.
FK to referral.ReferralNum.
FK to patient.PatNum.
Order to display in patient info. Will be automated more in future.
Date of referral.
true=from, false=to
Enum:ReferralToStatus 0=None,1=Declined,2=Scheduled,3=Consulted,4=InTreatment,5=Complete.
0=None,1=Declined,2=Scheduled,3=Consulted,4=InTreatment,5=Complete
0
1
2
3
4
5
Why the patient was referred out, or less commonly, the circumstances of the referral source.
All info about a referral is stored with that referral even if a patient. That way, it's available for easy queries.
Primary key.
Last name.
First name.
Middle name or initial.
SSN or TIN, no punctuation. For Canada, this holds the referring provider CDA num for claims.
Specificies if SSN is real SSN.
Enum:DentalSpecialty
0
1
2
3
4
5
6
7
8
9
10
11
12
13
State
Primary phone, restrictive, must only be 10 digits and only numbers.
.
.
.
.
Holds important info about the referral.
Additional phone no restrictions
Can't delete a referral, but can hide if not needed any more.
Set to true for referralls such as Yellow Pages.
i.e. DMD or DDS
.
FK to patient.PatNum for referrals that are patients.
NPI for the referral
Keeps track of which product keys have been assigned to which customers. This datatype is only used if the program is being run from a distributor installation. A single customer is allowed to have more than one key, to accommodate for various circumstances, including having multiple physical business locations.
Primary Key.
FK to patient.PatNum. The customer to which this registration key applies.
The registration key as stored in the customer database.
General note about the registration key. Specifically, the note must include information about the location to which this key pertains, since once at least one key must be assigned to each location to be legal.
This will help later with tracking for licensing.
This is used to completely disable a key. Might possibly even cripple the user's program. Usually only used if reassigning another key due to abuse or error. If no date specified, then this key is still valid.
This is used when the customer cancels monthly support. This still allows the customer to get downloads for bug fixes, but only up through a certain version. Our web server program will use this date to deduce which version they are allowed to have. Any version that was released as a beta before this date is allowed to be downloaded.
This is assigned automatically based on whether the registration key is a US version vs. a foreign version. The foreign version is not able to unlock the procedure codes. There are muliple layers of safeguards in place.
Each row represents one charge that will be added monthly.
Primary key
FK to patient.PatNum.
FK to procedurecode.ProcCode. The code that will be added to the account as a completed procedure.
The amount that will be charged. The amount from the procedurecode will not be used. This way, a repeating charge cannot be accidentally altered.
The date of the first charge. Charges will always be added on the same day of the month as the start date. If more than one month goes by, then multiple charges will be added.
The last date on which a charge is allowed. So if you want 12 charges, and the start date is 8/1/05, then the stop date should be 7/1/05, not 8/1/05. Can be blank (0001-01-01) to represent a perpetual repeating charge.
Any note for internal use.
For Dental Schools. Requirements needed in order to complete a course.
Primary key.
.
FK to schoolcourse.SchoolCourseNum. Never 0.
FK to schoolclass.SchoolClassNum. Never 0.
For Dental Schools. The purpose of this table changed significantly in version 4.5. This now only stores completed requirements. There can be multiple completed requirements of each ReqNeededNum. No need to synchronize any longer.
Primary key.
FK to reqneeded.ReqNeededNum.
.
FK to schoolcourse.SchoolCourseNum. Never 0.
FK to provider.ProvNum. The student. Never 0.
FK to appointment.AptNum.
FK to patient.PatNum
FK to provider.ProvNum
The date that the requirement was completed.
Many-to-many relationship connecting Rx with DiseaseDef.
Primary key.
FK to rxdef.RxDefNum.
FK to diseasedef.DiseaseDefNum
Rx definitions. Can safely delete or alter, because they get copied to the rxPat table, not referenced.
Primary key.
The name of the drug.
Directions.
Amount to dispense.
Number of refills.
Notes about this drug. Will not be copied to the rxpat.
One Rx for one patient. Copied from rxdef rather than linked to it.
Primary key.
FK to patient.PatNum.
Date of Rx.
Drug name.
Directions.
Amount to dispense.
Number of refills.
FK to provider.ProvNum.
Notes specific to this Rx.
One block of time that overrides the default sched. Either for practice, provider, or blockout.
Primary key.
Date for this timeblock.
Start time for this timeblock.
Stop time for this timeblock.
Enum:ScheduleType 0=Practice,1=Provider,2=Blockout,3=Employee. Practice is used as a way to indicate holidays and as a way to put a note in for the entire practice for one day. But whenever type is Practice, times will be ignored.
For schedule timeblocks.
0
1
2
3
FK to provider.ProvNum if a provider type.
FK to definition.DefNum if blockout. eg. HighProduction, RCT Only, Emerg.
This contains various types of text entered by the user.
Enum:SchedStatus enumeration 0=Open,1=Closed,2=Holiday. All blocks have a status of Open, but user doesn't see the status. The "closed" status was previously used to override the defaults when the last timeblock was deleted. But it's nearly phased out now. Still used by blockouts. Holidays are a special type of practice schedule item which do not have providers attached.
Schedule status. Open=0,Closed=1,Holiday=2.
0
1
2
FK to operatory.OperatoryNum. Only used right now for Blockouts. If 0, then it applies to all ops.
FK to employee.EmployeeNum.
Used in public health.
Primary key, but allowed to change. Change is programmatically synchronized so that keys stay intact.
Optional. Usage varies.
Used in dental schools. eg. Dental 2009 or Hygiene 2007.
Primary key.
The year this class will graduate
Description of this class. eg Dental or Hygiene
Used in dental schools. eg OP 732 Operative Dentistry Clinic II.
Primary key.
Alphanumeric. eg PEDO 732.
eg: Pediatric Dentistry Clinic II
Used in public health. This screening table is meant to be general purpose. It is compliant with the popular Basic Screening Survey. It is also designed with minimal foreign keys and can be easily adapted to a palm or pocketPC. This table can be used with only the screengroup table, but is more efficient if provider, school, and county tables are also available.
Primary key
The date of the screening.
FK to school.SchoolName, although it will not crash if key absent.
FK to county.CountyName, although it will not crash if key absent.
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
FK to provider.ProvNum. ProvNAME is always entered, but ProvNum supplements it by letting user select from list. When entering a provNum, the name will be filled in automatically. Can be 0 if the provider is not in the list, but provName is required.
Required.
Enum:PatientGender
0
1
2- This is not a joke. Required by HIPAA for privacy.
Enum:PatientRace and ethnicity.
Race and ethnicity for patient. Used by public health.
0
1
2
3
4
5
6
7
8
9
Enum:PatientGrade
Grade level used in public health.
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Age of patient at the time the screening was done. Faster than recording birthdates.
Enum:TreatmentUrgency
For public health. Unknown, NoProblems, NeedsCarE, or Urgent.
Enum:YN Set to true if patient has cavities.
Unknown,Yes, or No.
0
1
2
Enum:YN Set to true if patient needs sealants.
Unknown,Yes, or No.
0
1
2
Enum:YN
Unknown,Yes, or No.
0
1
2
Enum:YN
Unknown,Yes, or No.
0
1
2
Enum:YN
Unknown,Yes, or No.
0
1
2
Enum:YN
Unknown,Yes, or No.
0
1
2
Optional
FK to screengroup.ScreenGroupNum.
The order of this item within its group.
.
Used in public health. Programming note: There are many extra fields in common with the screen table, but they are only in this struct and not in the database itself, where that data is stored with the individual screen items. The data in this table is irrelevant in reports. It is just used to help organize the user interface.
Primary key
Up to the user.
Date used to help order the groups.
Stores an ongoing record of database activity for security purposes. User not allowed to edit.
Primary key.
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
33
FK to user.UserNum
The date and time of the entry. It's value is set when inserting and can never change. Even if a user changes the date on their ocmputer, this remains accurate because it uses server time.
The description of exactly what was done. Varies by permission type.
FK to patient.PatNum. Can be 0 if not applicable.
This defines the light buttons on the left of the main screen.
Primary key.
The text on the button
0-based index defines the order of the buttons.
0=none, or 1-9. The cell in the 3x3 tic-tac-toe main program icon that is to be synched with this button. It will light up or clear whenever this button lights or clears.
Blank for the default buttons. Or contains the computer name for the buttons that override the defaults.
This table stores references to the sequence of sounds and lights that should get sent out with a button push.
Primary key.
FK to sigbutdef.SigButDefNum A few elements are usually attached to a single button.
FK to sigelementdef.SigElementDefNum, which contains the actual sound or light.
These are the actual elements attached to each signal that is sent. They contain references to the sounds and lights that should result.
Primary key.
FK to sigelementdef.SigElementDefNum
FK to signal.SignalNum.
This defines the items that will be available for clicking when composing a manual message. Also, these are referred to in the button definitions as a sequence of elements.
Primary key.
If this element should cause a button to light up, this would be the row. 0 means none.
If a light row is set, this is the color it will turn when triggered. Ack sets it back to white. Note that color and row can be in two separate elements of the same signal.
Enum:SignalElementType 0=User,1=Extra,2=Message.
0=User,1=Extra,2=Message.
0-To and From lists. Not tied in any way to the users that are part of security.
Typically used to insert "family" before "phone" signals.
Elements of this type show in the last column and trigger the message to be sent.
The text that shows for the element, like the user name or the two word message. No long text is stored here.
The sound to play for this element. Wav file stored in the database in string format until "played". If empty string, then no sound.
The order of this element within the list of the same type.
An actual signal that gets sent out as part of the messaging functionality.
Primary key.
Text version of 'user' this message was sent from, which can actually be any description of a group or individual.
Enum:InvalidTypes None, Date, or combined flags for any LocalData
When the autorefresh message is sent to the other computers, this is the type. Keep in mind that this is a default Int32 type,so the max is 2,147,483,647 unless we change the type.
0
1- Not used with any other flags
2
4
8- Also includes appt rules
16
32
64
128- Also includes Signal/message defs.
256
512- Also includes DisplayFields
1024. Also includes payperiods.
2048
4096
8192. Also includes diseases.
16384
32768
65536
131072
262144
524288 Also includes Image Mounts
1048576 Also includes clinics.
2097152. No longer used.
4194304
8388608 Also includes patientfields
16777216
33554432
67108864. Includes AccountingAutoPay.
All flags combined except Date.
If IType=Date, then this is the affected date in the Appointments module.
Enum:SignalType Button, or Invalid.
The type of signal being sent.
0- Includes text messages.
1
This is only used if the type is button, and the user types in some text. This is the typed portion and does not include any of the text that was on the buttons. These types of signals are displayed in their own separate list in addition to any light and sound that they may cause.
The exact server time when this signal was entered into db. This does not need to be set by sender since it's handled automatically.
Text version of 'user' this message was sent to, which can actually be any description of a group or individual.
If this signal has been acknowledged, then this will contain the date and time. This is how lights get turned off also.
A company that provides supplies for the office, typically dental supplies.
Primary key.
The customer ID that this office uses for transactions with the supplier
Full address to website. We might make it clickable.
The username used to log in to the supplier website.
The password to log in to the supplier website. Not encrypted or hidden in any way.
Any note regarding supplier. Could hold address, CC info, etc.
A dental supply or office supply item.
Primary key.
FK to supplier.SupplierNum
The catalog item number that the supplier uses to identify the supply.
The description can be similar to the catalog, but not required. Typically includes qty per box/case, etc.
FK to definition.DefNum. User can define their own categories for supplies.
The zero-based order of this supply within it's category.
The level that a fresh order should bring item back up to. Can include fractions. If this is 0, then it will be displayed as having this field blank rather than showing 0. This simply gives a cleaner look.
If hidden, then this supply item won't normally show in the main list.
The price per unit that the supplier charges for this supply. If this is 0.00, then no price will be displayed.
One supply order to one supplier. Contains SupplyOrderItems.
Primary key.
FK to supplier.SupplierNum.
A date greater than 2200 (eg 2500), is considered a max date. A max date is used for an order that was started but has not yet been placed. This puts it at the end of the list where it belongs, but it will display as blank. Only one unplaced order is allowed per supplier.
The sum of all the amounts of each item on the order. If any of the item prices are zero, then it won't auto calculate this total. This will allow the user to manually put in the total without having it get deleted.
One item on one supply order. This table links supplies to orders as well as storing a small amount of additional info.
Primary key.
FK to supplyorder.supplyOrderNum.
FK to supply.SupplyNum.
How many were ordered.
Price per unit on this order.
A task is a single todo item.
Primary key.
FK to tasklist.TaskListNum. If 0, then it will show in the trunk of a section.
Only used if this task is assigned to a dated category. Children are NOT dated. Only dated if they should show in the trunk for a date category. They can also have a parent if they are in the main list as well.
FK to patient.PatNum or appointment.AptNum. Only used when ObjectType is not 0.
The description of this task. Might be very long.
True if the task has been completed. This could later be turned into an enumeration if more statuses are needed.
True if it is to show in the repeating section. There should be no date. All children and parents should also be set to IsRepeating=true.
Enum:TaskDateType None, Day, Week, Month. If IsRepeating, then setting to None effectively disables the repeating feature.
0
1
2
3
FK to task.TaskNum If this is derived from a repeating task, then this will hold the TaskNum of that task. It helps automate the adding and deleting of tasks. It might be deleted automatically if not are marked complete.
Enum:TaskObjectType 0=none,1=Patient,2=Appointment. More will be added later. If a type is selected, then the KeyNum will contain the primary key of the corresponding Patient or Appointment. Does not really have anything to do with the ObjectType of the parent tasklist, although they tend to match.
Used when attaching objects to tasks. These are the choices.
0
1
2
The date and time that this task was added. Used to sort the list by the order entered.
Represents one ancestor of one task. Each task will have at least one ancestor unless it is directly on a main trunk. An ancestor is defined as a tasklist that is higher in the heirarchy for the task, regardless of how many levels up it is. This allows us to mark task lists as having "new" tasks, and it allows us to quickly check for new tasks for a user on startup.
Primary key.
FK to task.TaskNum
FK to tasklist.TaskListNum
A tasklist is like a folder system, where it can have child tasklists as well as tasks.
Primary key.
The description of this tasklist. Might be very long, but not usually.
FK tasklist.TaskListNum The parent task list to which this task list is assigned. If zero, then this task list is on the main trunk of one of the sections.
Optional. Set to 0001-01-01 for no date. If a date is assigned, then this list will also be available from the date section.
True if it is to show in the repeating section. There should be no date. All children should also be set to IsRepeating=true.
Enum:TaskDateType None, Day, Week, Month. If IsRepeating, then setting to None effectively disables the repeating feature.
0
1
2
3
FK to tasklist.TaskListNum If this is derived from a repeating list, then this will hold the TaskListNum of that list. It helps automate the adding and deleting of lists. It might be deleted automatically if no tasks are marked complete.
Enum:TaskObjectType 0=none, 1=Patient, 2=Appointment. More will be added later. If a type is selected, then this list will be visible in the appropriate places for attaching the correct type of object. The type is not copied to a task when created. Tasks in this list do not have to be of the same type. You can only attach an object to a task, not a tasklist.
Used when attaching objects to tasks. These are the choices.
0
1
2
The date and time that this list was added. Used to sort the list by the order entered.
A subscription of one user to either a tasklist or to a task.
Primary key.
FK to userod.UserNum
FK to tasklist.TaskListNum
Each row is one computer that currently acting as a terminal for new patient info input.
Primary key.
The name of the computer where the terminal is active.
Enum:TerminalStatusEnum Indicates at what point the patient is in the sequence. 0=standby, 1=PatientInfo, 2=Medical, 3=UpdateOnly. If status is 1, then nobody else on the network can open the patient edit window for that patient.
Indicates at what point the patient is in the sequence. 0=standby, 1=PatientInfo, 2=Medical, 3=UpdateOnly.
0
1
2
3. Only the patient info tab will be visible. This is just to let patient up date their address and phone number.
FK to patient.PatNum. The patient currently showing in the terminal. 0 if terminal is in standby mode.
Used on employee timecards to make adjustments.
Primary key.
FK to employee.EmployeeNum
The date and time that this entry will show on timecard.
The number of regular hours to adjust timecard by. Can be + or -.
Overtime hours. Usually +. Usually combined with a - adj to RegHours.
.
Each row represents one toolbar button to be placed on a toolbar and linked to a program.
Primary key.
FK to program.ProgramNum.
Enum:ToolBarsAvail The toolbar to show the button on.
0
1
2
3
4
5
6
7 Shows in the toolbar at the top that is common to all modules.
The text to show on the toolbar button.
Used to track missing teeth, primary teeth, and movements
Primary key.
FK to patient.PatNum
1-32 or A-Z. Supernumeraries not supported here yet.
Enum:ToothInitialType
0
1
2
3
4
5
6
7
8
Shift in mm, or rotation / tipping in degrees.
Used in the accounting section of the program. Each row is one transaction in the ledger, and must always have at least two splits. All splits must always add up to zero.
Primary key.
Not user editable. Server time.
FK to user.UserNum.
FK to deposit.DepositNum. Will eventually be replaced by a source document table, and deposits will just be one of many types.
FK to payment.PayNum. Like DepositNum, it will eventually be replaced by a source document table, and payments will just be one of many types.
A treatment plan saved by a user. Does not include the default tp, which is just a list of procedurelog entries with a status of tp. A treatplan has many proctp's attached to it.
Primary key.
FK to patient.PatNum.
The date of the treatment plan
The heading that shows at the top of the treatment plan. Usually 'Proposed Treatment Plan'
A note specific to this treatment plan that shows at the bottom.
The encrypted and bound signature in base64 format. The signature is bound to the byte sequence of the original image.
True if the signature is in Topaz format rather than OD format.
A group of users. Security permissions are determined by the usergroup of a user.
Primary key.
.
(User OD since user is a reserved word) Users are a completely separate entity from Providers and Employees even though they can be linked. A usernumber can never be changed, ensuring a permanent way to record database entries and leave an audit trail. A user can be a provider, employee, or neither.
Primary key.
.
The password hash, not the actual password. If no password has been entered, then this will be blank.
FK to usergroup.UserGroupNum. Every user belongs to exactly one user group. The usergroup determines the permissions.
FK to employee.EmployeeNum. Cannot be used if provnum is used. Used for timecards to block access by other users.
FK to clinic.ClinicNum. If 0, then user has access to all clinics.
FK to provider.ProvNum. Cannot be used if EmployeeNum is used.
Set true to hide user from login list.
A list of query favorites that users can run.
Primary key.
Description.
The name of the file to export to.
The text of the query.
Zipcodes are also known as postal codes. Zipcodes are always copied to patient records rather than linked. So items in this list can be freely altered or deleted without harming patient data.
Primary key.
The actual zipcode.
.
.
If true, then it will show in the dropdown list in the patient edit window.