Adrian,
I completely agree with the approach you are suggesting. It is the
philosophy we are employing with Circare.... we are working to make it the
indexing system for both praciitce management systems and hospital systems
etc. in the Hamilton Ontario health region, independent of the legacy
systems.
My background is in strategic planning for IT and one big lesson we learned
in the other industries I worked in is that the right size "lego block" is
critical to balancing cost, flexibility and functionality. Getting it wrong
puts you in a straight jacket which is very costly and time consuming to get
out of!
Joseph
Joseph Dal Molin
Office: 1.416.232.1206
Cell Phone: 1.416.818.9156
----- Original Message -----
From: Adrian Midgley <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, November 21, 1999 6:31 AM
Subject: Re: Tables, Kernels & Middleware (was: Re: So far...)
> As a GP (family medical practitioner) I have been considering record
systems
> from the viewpoint of the questions I ask the record.
> Not just at the point and time of care, but also afterward, over the whole
> registered practice population, over the whole population at a time or
over
> all time and so on, but the main one because time is critical at the point
> of care is the questions asked of the record at that time.
>
> Going from this to the underlying structure of the data, I believe we must
> accept that the systems will always be distributed, or at least the data
> will be, since all care is never within the context of a single provider
at
> a single site and rarely within the context of facilities owned by a
single
> org. Even the NHS behaves far more like a cloud of loosely related
> independent bodies than a single service (to the patient's detriment and
> only partly repairable by fixing the record systems but I digress).
>
> Thus an ability to store a pointer to information, together with a pointer
> to scripts to authenticate with each of an arbitrarily large number of
hosts
> of information is needed. THis is current technology though. IMHO as
much
> as possible of this should be left outside the core of the medical record
> system.
>
> The system must also be prepared to act as a host in answering such
requests
> from elsewhere (with the patient's consent and so on).
>
> This sort of approach seems to me to make it easier to preserve a relative
> independence on the precise form of the underlying data storage - tables,
> marked up files, and so on.
> Envisage a large group of functions which will tend to have similar names
(a
> tendency reinforced by the publication of the names in use in various
> projects) and return the same information. On the one hand they know the
> sturcture of their own data tables etc, anod on the other hand they could
be
> called by several different programs, and on the third hand they can be
> replaced one by one by identically named fucntions with identical output
> dealing with wholly different underlying data stores, as commonality or
> divergence occurs.
>
> This is middleware of sorts.
>
>
>
