Hello Adrian

> Are we really sure that having one (composite) file per patient is a bad way
to keep records?
<snip>
> I like the idea of the patient record as a discrete object more and more.

I believe that we can have our cake and eat it by having systems and data that
are object oriented. I see more flexibility where a record (e.g. patient record)
is made up of numerous sub-objects that can be held and processed independently
yet can also be collected together to form a single logical view.

To my mind IT systems have taken an overtly applications view of the world to
the detriment of users' ability to manage *all* their information. Those of us
with long memories of IT will have seen application systems come and go yet the
data lives on. Health and Insurance are two industries where there are
contractual reasons for maintaining data over a long period. Of course, the
suppliers of applications have a vested interest in locking you into their
systems and making any conversion difficult.

As the scope of information increases users will invariably need to handle more
data types. Thus from basic structured text containing such items as names,
addresses and problems, users are starting to record correspondence (free text),
x-rays (image), sketches (drawings), telephone conversations (voice), and later
will come consultations (video). Users may well find their applications supplier
lagging in their ability to extend their systems. This may be for technical or
resource reasons or simply a return on investment decision. Further the supplier
may not provide the best implementation (jack of all trades, master of none).
For example, a lot of skill is required to develop image systems. Ideally the
user should be able to buy a better image processor and plug it into their
application system - in fact the concept of a single application system needs to
be dropped.

True object oriented (OO) systems have the basis of extendibility. Having
personally used an object based office system for 4 years, and used a similar
system for developing prototype GP practice system, I have experienced how
productive and flexible such systems can be.

>From your other posting:
> What is the logical reason for recording physiotherapy treatment or a minor
operation in a separate manner and part of the database from the prescription of
a drug?<

A decent OO system should allow the same object to be referenced from more than
one container object. To use your example, a drug issue could be referenced from
within the treatment container (which in turn would be referenced by the patient
container) and also referenced via the FP10s container which is under the HA. A
third reference could be in the pharmaceutical suppliers container.

Of course creating these references takes time. One solution is to invoke an
agent task every time an object is created. E.g. an agent tasks is associated
with create drug issue object. It automatically runs and notes which
pharmaceutical company makes the (non generic) drug and then automatically
creates the reference. Alternatively, where references are only used on an
ad-hoc basis it might be acceptable to scan all the drug issue objects to count
say all issues for a particular pharmaceutical.


> Perhaps one could embed code which caused each patient record to display
properties corresponding
to the more commonly searched conditions, so they could be rapidly looked
through by a program with appropriate permissions.<

Properties are inherent in OO systems and a good system should allow users to
define their own properties as well as provide powerful search tools. Such tools
should provide logical (AND, OR, NOT etc.) and natural language searches not
just on the individual objects but also on their relationships. (e.g. List all
Chest X-rays from 1/1/96 to 1/10/96 with abnormal growth belonging to Asthma
patients who live in Winchester).

A possible downside when many people are adding to the database is consistency
of property values, and this is no different to the problems of consistent Read
code allocation. In a similar way to read codes, it would be useful to have a
selection list of values for each property. This would also help avoid
mistyping. Free text engines and their equivalent for other data types can
supplement object properties.

For example, I save web pages to hard disk but for time reasons rarely import
them into my object office system. Instead I use a free text engine to index
their HTML content and then, when needed, I search for various keyword
combinations. When I do import them I can drag and drop them into their relevant
container object (e.g. select AAH's home page and drop it into into AAH's folder
along with all my correspondence with them).

> Against that of course there are the conveniences of searching quickly on
large homogenous files of the whole practice,<

As the database holds more and more information of even more complex types then
an OO implementation allows the database administrator to physically split and
store the data for optimum performance. I would surmise that if you wanted to
search for say all patients seen at St Mary's hospital then you would probably
limit to searching all the correspondence objects. A search through the whole
database could get very slow if there were say substantial x-ray images within
it. Of course any search on just the property values would be fast as these are
likely to be held in a separate file.

I was at an OO seminar last week and the presenter was raving on about the good
performance in their OO system as it used direct pointers and it was possible to
control the physical placement of the data. He compared this to the poor
performance of relational systems. I had a chuckle to myself as 20 years ago I
was doing just what he said using network databases. There is rarely anything
new, but more often than not, repackaging of good ideas :-)

Regards
Alan

Alan Cooper, Managing Change
E-mail: [log in to unmask], Tel & Fax: +44 (0)1264 737609
S-mail: Change House, Shepherds Rise, Vernham Dean, Andover, Hampshire, SP11
0HD, England
Managing Change means "A proactive approach to change"



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%