UNIVERSITY COMMENTS
In implementing ViewPoint into an orthodontic
program, two issues must be considered. First, the program
is written for a private practice which may have one or more
doctors and assistants and one or more offices which see 50
to 60 patients per day on average while the university will
typically have many more doctors and may see many more
patients in a given day. Secondly, the private practice will
have fewer individuals involved in deciding how the program
should be customized and used than in the university
setting. Both of these issues are important and must be
addressed to successfully implement the use of ViewPoint in
your department. Here are some considerations:
SCHEDULING
In a private practice, the scheduling system has to consider
the doctor, the patient and perhaps the assistant and/or the
column or chair. In the university, we have to add the
resident to the above list. ViewPoint has fields for the
orthodontist, the family dentist, the referring party, the
assistant and the office all of which are unlimited in
number. In a university setting, we need to decide how to
"trick" the system so, e.g., the attending = orthodontist,
the resident = the family dentist and the assistant =
assistant. We have set this up in different ways at various
universities and can customize this feature so that it does
just what you want. The main implication is the way reports
are affected.
Another issue in designing the scheduling system for the
university has to do with the fact that the attending can
only be in one place at one time. Imagine Dr. Scholz
entering the clinic of 42 chairs at 9:00 AM on Wednesday and
being needed by 30 residents all at the same time! While
this may seem to be an absurd example, SLU does have 42
chairs and an equal number of residents who on occasion are
all present in the clinic at the same time. We solved this
by using color coding to identify attendings so there is a
bright visual on screen when appointing patients to avoid
this problem.
FINDINGS
ViewPoint has a feature we call findings. It is a series of
fields that are totally user definable and unlimited in the
number of categories and responses. This feature is used in
three ways:
- Its data can be merged to the insurance form
- Its data can be merged to the word processor and on
the way can automatically be translated into parent
vocabulary and/or dentist vocabulary.
- The data can be sorted using Boolean logic to find
any number of patients meeting specific search criteria.
So if a resident wanted a list of treated patients who
were Class I, with overjet and overbite of so much, were
female, who started treatment between ages 11.6 and 14.8
and who went at least four months past their expected
treatment time, one pass on the database would provide
the list. This will be the major use of the findings
feature in a university setting.
Two issues come to mind in deciding what your departments
finding page should look like. First, how will it be used
which will define specificity and who will design it?
On the subject of specificity, and example could be how
we want to record the amount of overjet in a given patient.
Should we record negative, normal, a little bit, a lot and
severe? The problem with this approach is that it will not
produce a good list of cases as when I record the response
as a lot, you might use the severe response. The advantage
is that our response list will be short and easy to use. If
we go toward more specificity, like -5-3mm, -1-0mm, 1-3mm,
4-6mm our response list increases and will be more difficult
to use. To further complicate the matter, some may want to
be really specific like -5mm, -4mm, -3mm etc. this will make
the list extremely long and quite difficult to use.
The who will design it issue is most important as if the
users are not involved in the design process, they will not
use it. What has worked is that a committee of faculty,
residents and perhaps staff come up with a draft of what
they think should be done and circulate it to all faculty
and residents for input and comments. Only after everyone
has agreed on the design should it be implemented into
ViewPoint.
SOLOING
Here are my definitions of "soloing". Soloing means a
resident sees a patient assigned to an attending without any
attending seeing the patient during a visit. Semi-soloing
means a resident sees a patient and an attending does see
the patient but not the attending assigned to that patient.
Both of these problems exist in most of the orthodontic
departments I have visited and two things are of interest.
First, when I ask the Chairperson or Clinic Director or
Program Chair if the residents do such a thing, I typically
get a very positive "no". Secondly, few programs have a
bullet proof system of tracking this problem so we don't
really know if it goes on and if it does, to what extent. I
have seen the system in which the attending must sign the
chart but this means the charts have to be collected and
reviewed and many times this is where it fails.
I recently visited a program and asked the Chair if his
residents are soloing or semi-soloing and got a "no way"
response. But in conversing with several second year
residents who had just been transferred the patients
previously treated by the now graduates, I got a very
different answer. Each student reported that they had
several patients that had not been seen by any attending for
a full year! I think you will agree that this is a
significant problem and needs to be addressed.
ViewPoint has a very nice electronic treatment plan and
chart capability which can be used to track this problem.
Using a fingerprint reader, a resident could "sign in" so
the computer knows who is entering data. When the attending
sees the patient, he/she could fingerprint into the system
and note that the patient has been seen. At present, an
audit of treatment chart entries would be necessary but I
think the day is coming when ViewPoint could include this
information in a report.
UNIVERSITY REPORTS
During my tenure at UCSF, a common problem was collecting
the information to know that the patients I had with each of
the residents was being seen in a timely fashion and
progressing well in treatment. Now that the computer has
arrived, we can do this quite easily. Ortho II has designed
a university report which can be printed with one pass on
the data base and distributed to attendings and residents.
It looks something like this and the fields can be changed
if a program wants different information.
| DR. SCHOLZ/RESIDENT SMITH |
| NAME |
START
DATE |
COMPLETION |
MONTHS |
LAST
VISIT |
NEXT
VISIT |
NEXT
VISIT |
AGE |
BALANCE |
AMT
DUE |
| Pat 1 |
1/3/2004 |
12/3/2005 |
21 or 24 |
7/28/2004 |
8/30/2004 |
Bonding |
13.4 |
300 |
100 |
| Pat 2 |
6/5/2004 |
5/5/2006 |
2 of 24 |
7/10/2004 |
8/13/2004 |
Adjust |
12.8 |
2100 |
0 |
| Pat 3 |
4/2/2005 |
3/2/2004 |
29 of 24 |
5/22/2004 |
none |
Adjust |
14.6 |
900 |
900 |
| |
| DR. SCHOLZ/RESIDENT JONES |
| Pat 1 |
1/3/2004 |
12/3/2005 |
21 of 24 |
7/28/2004 |
8/30/2004 |
Bonding |
13.4 |
300 |
100 |
| Pat 2 |
6/5/2004 |
5/5/2006 |
2 of 24 |
7/10/2004 |
8/13/2004 |
Adjust |
12.8 |
2100 |
0 |
| Pat 3 |
4/2/2004 |
3/2/2004 |
29 of 24 |
5/22/2004 |
none |
Adjust |
14.6 |
900 |
900 |
| |
| DR. WHITE/RESIDENT SMITH |
| Pat 1 |
1/3/2004 |
12/3/2005 |
21 of 24 |
7/28/2004 |
8/30/2004 |
Bonding |
13.4 |
300 |
100 |
| Pat 2 |
6/5/2004 |
5/5/2006 |
2 of 24 |
7/10/2004 |
8/13/2004 |
Adjust |
12.8 |
2100 |
0 |
| Pat 3 |
4/2/2004 |
3/2/2004 |
29 of 24 |
5/22/2004 |
none |
Adjust |
14.6 |
900 |
900 |
| |
| DR. WHITE/RESIDENT JONES |
| Pat 1 |
1/3/2004 |
12/3/2005 |
21 of 24 |
7/28/2004 |
8/30/2004 |
Bonding |
13.4 |
300 |
100 |
| Pat 2 |
6/5/2004 |
5/5/2006 |
2 of 24 |
7/10/2004 |
8/13/2004 |
Adjust |
12.8 |
2100 |
0 |
| Pat 3 |
4/2/2004 |
3/2/2004 |
29 of 24 |
5/22/2004 |
none |
Adjust |
14.6 |
900 |
900 |
This report can be sorted by resident so they can
see a summary of how their patient care is progressing.
THE DEAN'S SYSTEM
Almost every dental school I have visited has a school wide
computer system that I call "The Dean's System". Some are
built in house while other schools use off the shelf
programs intended for use in every department. The most
commonly used are the Axium and Windent programs. The
problem with these non-orthodontic applications is that
while they try to some extent to be department specific they
never get there so the orthodontic department has to
undertake some form of double entry to accomplish the tasks
missed by the dean's system. The most common missing element
is the subject of findings noted above. I have never seen a
dean's system able to deliver the same results that a
properly designed ViewPoint findings list can produce. Other
areas include scheduling, the electronic treatment chart,
word processing and image integration.
A very common "brick wall" I find at dental schools is that
the Dean (or whomever the decision maker may be) won't allow
another program to be used in the school. While there may be
some logical reasons for this policy, some are illogical and
can be solved. The most common problem foreseen is "lack of
control" by the powers that be and this is usually in the
financial arena. It seems that the Dean may have to report
to the auditors about the financial performance of the
entire school in a meaningful fashion. Therefore reports
from all departments in the same format would be desirable
so they can be shown in detail and summarized. There are two
ways around this problem. First, let the school collect the
orthodontic department fees and use the dean's system to do
this. We need to be careful as if the school's collection
staff is not effective, we have to be able to know it and
then be able to do something about it. Another solution we
used at North Carolina is that the Ortho II and dean's
system programmers put their heads together, collaborated
and built a bridge between the two programs. The end result
is that the money is collected in the orthodontic
department, both for the clinic and faculty practice
operations, posted in ViewPoint then uploaded into the
dean's system at night. The end result is control is
maintained by the orthodontic department and the dean's
reports all have the same look.
IMAGING AND RADIOGRAPHS
This issue can be very problematic but doesn't have to be if
it addressed correctly. Let's assume for discussion that you
are using ViewPoint, an imaging program and we have a direct
or indirect digital radiography system. The objective is to
be able to interface with imaging which in turn is
interfaced with radiography so a resident or faculty member
can easily view digital pictures and radiographs on a screen
located in the clinic. ViewPoint is interfaced with imaging
so clicking on the smiling face in the patient's record
opens the imaging program and images can be viewed.
Radiographs are no so easy. Typically, a patient panorex or
ceph is exposed and stored using the proprietary software
that is provided by the radiography system. Generally, the
dean's system is interfaced with the radiography software so
a student can get to the image from the dean's systems
patient record. But not from ViewPoint! The resident has to
find the proper record either through the dean's system or
the radiography system, export it to a convenient server in
a suitable format then import it into the imaging system so
it can be accessed from ViewPoint. At least part of this
step can be automated with a bit of programming by the
dean's system programmers. The step would be to ask the
technician after exposing and saving the image if this image
would like to be exported as well to the "ortho server". If
the response is positive, the system would save the file on
a computer convenient to the residents for importing into
the imaging system.
THE BIG PICTURE AT THE UNIVERSITY
Having spent twenty years at UCSF as a faculty member in the
orthodontic department, I think the only thing that allowed
my survival was the fact that I could return the next day to
private practice and get things done efficiently without
having to put up with the bureaurocracy offered in the
university setting. My last ten years at UCSF were under the
chairmanship of Bob Isaacson, one of orthodontics leading
educators in my time. When we were puzzled by something
going on at school, Bob would query, "How do we do this
downtown?" Many times this answered the question about how
we should do something at school. It further developed my
image of what an orthodontic program should offer its
residents and that is an environment that closely resembles
"downtown". Our office has a computer and flat screen at
every chair, electronic treatment chart, a great interface
to imaging so I can show Mom the panorex and send an
electronic referral to the oral surgeon for removal of the
third molars. Every workstation is Internet capable and
firewalled. Why should the university be any different?
Click here to view the
Ortho II policies on software donations to orthodontic
departments.

| Home |
Cone Beam |
AAO Presentations -- Doctors / Staff |
Universities |
Graduate Program |
Radiology |
Opportunities |
Page last updated on
Thursday, May 15, 2008 10:01 AM.
|