At present all dental software that runs dental computer systems that transmit to the DPB via the Racal Healthlink+ Kermit transfer link (EDI) is closed source running almost exclusively on Microsoft operating systems DOS, Windows (3.x `95 `98 2000 or NT). It is my opinion that this situation will not last forever as dental computing fulfils all the discriminators that push towards "open - source" mentioned by Eric S. Raymond in his book "The Cathedral and the Bazaar" page 175.
1. Reliability, stability, and scalabilty are critical.
2. Correctness of design and implementation cannot readily be verified by means other than independent peer review.
3. The software is critical to the control of his or her business.
4. The software establishes a common computing and communications infrastructure.
5. Key methods (or their functional equivalents) are part of common engineering knowledge.
Only one "discriminator" needs to apply to make "open-source" code desirable for end-users.
More and more dental practices are installing full clinical systems and developing networks, mostly on a
small scale, but in 1999 Integrated Dental Holdings (IDH) signed a £1 million contract to fit a 350 surgery
network.(£2857 each) I am a single handed dentist. My surgery used to send all my patient forms (National Health Service)
for payment by the DPB (Dental Practice Board) by EDI (Electronic data interchange). This was done using a Windows 486
machine with 4mb ram and it worked very well for about 5 years until just before Y2K. The modem packed up
and as the computer was not capable of being Y2K compliant I decided to shut it down and go back to
sending the forms by "snail mail", and let the DPB input them for payment. My way of dealing with the
millenium bug! The main benefit of running a computer based system for me was that the forms could be
input by a receptionist and did not need to be signed by me. This left me able to concentrate on
seeing patients and thus earning more money. When I analyzed the costs of my computer system came up with roughly
the sort of figures below:- Once you choose and set up your network operating system you are effectively selecting an avenue of
investment and training costs. Your supplier knows this, and under these circumstances, the "closed - source" software
will change to meet software supplier's needs and business plan, and not the end users'. The end users will pay in high maintenance
costs, high upgrade costs and the "lock - in" will get more difficult to get out of. Contrast this with the "open - source" software choice. From day one you have the source code and no
one can take it away from you. You can show this to any prospective new software supplier (even if you don`t know
how to use it yourself), and theoretically you can modify your system to suit your own needs. User groups
of dentists would be able to pressurise suppliers to make needed adjustments much more easily than at
present.
Maintenance agreement
Hardware 1995 Initial Purchase, incl printer etc.
£2000
Racal (now Global Crossing) Kermit ftp link
Postage stamps
Data Protection Registration
Sundry repairs
Total cost over 5 years
Total cost per FP17 form sent over 5 years (24000 forms)
Thus over a period of 5 years the cost of the computer based system was about
£6000 and for this I sent about 24000 forms. This works out at 25p per form. By signing my forms
and sending them by post there was a saving of 22p per form. My former surgery based system was known
as a stand alone reception based system, however more and more dentists are starting to install surgery based
networks (if they have any computerisation at all) and these are more expensive (about £7 - 20000 per
2 - surgery practice with the reception based computer being the server - my practice has two surgeries).
These clinical systems can be used for all the patients records including medical histories as well
as payment forms, digital X - rays and photos.
Regarding dental computer database records. These are by their nature pretty complicated,
and often it is by no means easy to transfer data from one computer database to another. Much of this problem is due to lack of
common standards, and the desire of computer companies to keep the data secure, and also to preserve their "lock-in" control over
their users. Over time it can mean that data can't be carried over from one generation of computer software to the next. If the computer
company goes bankrupt it may mean that with source code escrows and the legal process that it is many months before it is
possible to transfer the data. If the dentist goes bankrupt, then it could mean problems for patients or health authorities
to get details to which they may be entitled. It may also be that some details cannot easily be passed from one dental
practice to another because they are using different proprietary products. These problems could be solved if regulations
required that patient details had to be held in such a way that they could be made available in an "open" format such as
HTML which can't be changed easily for commercial reasons.
Already some dentists have questioned the value that computerization brings to an NHS dental surgery. For example N Jones'
letter to the BDJ. Thirty five thousand pounds to network a large practice. The cost doesn't end there. Once trained
computer literate workers can command higher salaries. The cost of posting ("snail mail")FP17 forms to the DPB works out
at around 3p per form. For a computerized practice I estimate the cost is anywhere between 25p and 100p per FP17 form for
a reasonably busy NHS practice.
The millenium bug provided a good excuse to force dental practices to upgrade their systems, but now computer companies
have to rely on new features, takeovers and mergers to encourage constant upgrades. At the moment there are no easily
identifiable benchmarks to compare the various computer systems. Tony Lynn used to compare the various systems, but without
access to the source code this is only going to be superficial. The question of errors for forms handled by the DPB would
be solved if there was a common source code base for all companies to work with, so any advertisements about this as a benchmark
are merely wallpapering the faults of the present system. I suggest one benchmark could be the cost per form to transmit to the
DPB. It's not perfect, but I would reckon it is the main use as far as most NHS practitioners are concerned.
Next
Previous