Hi,

Wellcome in the bandwagon of the Document Paradigm.

(And. Don't tell me you never heard thoughts, like yours, before in this
list  :-)

By the way.
Databases stay handy when one has a birthday and name but not the
PatientNumber which is used as an index to the patientfiles.

In order to process all those patientfiles we need markup (XML) to make
information out of the data.
And all those labels will have to have names/terms and defined uses.

For the Document  Paradigm to succeed we need an uniform set of
Terminologies and Rules based on a General Domainmodel.
MedSpeak for short.
MedSpeak is a limited set of Domains (or Contexts) each with a limited set
of Terminologies describing Concepts and a set of rules.

Greetings

Gerard

ps: The future knowlegde is in Documents now.


At 5:40 PM +0100 9/6/97, Adrian Midgley wrote:
>All GP clinical record systems at present in widespread use
>use a database management system which lumps the various
>individual items of the records of each patient together.
>
>Some of the more avanced ones use a relational database,
>and some of the most successful and effective do not appear
>to use the relational model.
>
>The result is that if a problem develops with part of the
>database it is very likely to affect all patients.
>
>If this merely a matter of a polite notice appearing from
>the program that it was temporarily unable to provide
>details of previous immunisations (say) or the old
>addresses, and that it had identified the nature of the
>problem and was rectifying it behind the scenes but would
>meanwhile do its best to present the rest of the
>information held, this would be fairly tolerable.
>Unfortunately the error message tends to be less informative
>and placatory, and the program rather than failing
>gracefully into a limpalong mode while it sorts its
>troubles out - crashes.
>
>Reindexing a modern GP database proceeds fast, but the more
>elegant and Read code based the design the larger the
>data tables are likely to be and therefore the time
>required is liable to be long now and will be progressively
>longer in the future as records expand.
>
>The converse approach, as practiced in Surgery manager, of
>dividing information into many many tables and thus storing
>much of the meaning by context rather than explicit codes,
>could offer rapid repairs of the individual tables, and
>holds out the promise of a graceful degradation in
>performance if one or more tables is damaged, but in
>practice there has been insufficient attention paid to
>reporting the location of the failure and therefore the
>standad help-line advice of "reindex it all" is liable to
>be what one does.
>
>More complete diagnostic facilities would ease the task of
>the help-line,  thus rendering it less important that one
>is unable to get beyond queue position one or obtain a
>reply to e-mails.
>
>Given that the help-line service seems to be the one most
>difficult for all suplliers to satisfy their customers on
>increased diagnostic acumen built into the products would
>seem to be a useful advance.
>
>However, documents...
>---------------------------------
>Placing substantially the whole of the individual patient's
>record in a single file, group of files or even directory
>and presenting the internal structure through a suitably
>defined viewer, and altering it with a suitable series of
>commands through such a viewer seems to have much to
>commend it.
>
>One might lose an individual patient's notes, but would
>expect to retrieve them from backup, and meanwhile have no
>troubles with others.
>
>They could be encrypted, contain links to pictures or the
>images themselves, and in general be used as the
>word-processed documents they are.
>
>They could also rather conveniently be copied to another
>location, and a viewer provided - along the lines of
>Microsoft's Word viewer which permits inspection and
>extraction but not alteration.  If the format and the
>viewer were good then the supplier might reasonably hope to
>spread its use further.
>
>So Why Databases
>-----------------------------
>Well, firstly they were what was to hand.
>Secondly, the major impetus from the College and DoH
>was to run a card index, and although even then Grep and
>its ilk were effective search tools for disparate files,
>there is no doubt that a database is quicker for searching
>organised data.
>
>However, now with stunningly fast hardware, and with clever
>search engines and document indexing systems, and with the
>examples of marking up systems in use widely - the time has
>come to recreate teh electronic pateint record.
>
>
>
>--- OffRoad 1.9r registered to Adrian Midgley


Gerard Freriks,huisarts, MD
C. Sterrenburgstr 54
3151JG Hoek van Holland
the Netherlands  		Telephone: (+31) (0)174-384296/ Fax: -386249
				Mobile   : (+31) (0)6-54792800
ARS LONGA, VITA BREVIS




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