[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Sun, 2010-04-18 at 17:57 +0100, Simon Waters wrote:
> Adrian Midgley (Gmail) wrote:
> >
> > Writing code to allow a generic network facing interface to receive
> > questions from an authorised other node on the network and pass them to
> > a system-specific layer which turned those questions into actions on the
> > general practice* database is a simple scalable task which has been done
> > for many systems - indeed the stuff I'm using now has a Windows frame
> > around a terminal emulator that pretends to the database system that it
> > is a Wyse green screen terminal.
>
> I'd say not simple.
>
> You have N back ends,
n= EMIS, Systm One, iSoft, Vision, the Cornish one. At a pinch add on
GPASS but that is Scottish and not interfaced anyway. So not a large
number, 5.
EMIS dates to before 1990 (the first time I looked at it and thought it
was effective but not very good), Systm One whcih one may hope is
programmed better than it is spelled, is about 10 years old now. Not a
fast turnover.
MIQUEST, which is an implementation of a health query language (HQL)
which in turn is a superset of a subset of SQL, dates to 1994 or so and
solves many of these problems, although it is aimed at answering
questions about groups of patients
(Naive administrator: send us the entire medical record of all your
patients, we want to see how many of them have diabetes...
MIQUEST response to COUNT Patients with Diabetes = 234
Among several other benefits there is the tiny one of sending one number
back, rather than several gigabytes. We've been working on these
problems for long enough for people to leave school, get jobs, and start
trying to invent solutions that involve Excel without looking up what
they already have to hand.)
The solution of uploading all data and converting it in a new system
which then holds all data - except the bits that were invented after the
specification was given to EDS or Fujitsu or BT or CSC who have neitehr
proved incompetent nor failed at it, or Accenture whose message to their
shareholders was refreshingly honest when they pulled out, does not seem
to me to be either more comprehensive or less effort than writing the
translation for a list of questions for each system.
The NHS has long had an answer, and it is not a bad one, for new
systems, which is that an incoming new system in GP IT must do what the
existing ones do, as specifications.
So we publish a list of questions which are the questions that doctors
etc ask each other about patients "IsDiabetic(yes/no)",
ListAllergies(), HadThisDrug("Amoxicillin"), Int SystolicBP(), Int
(DiastolicBP(), *LabLabResults() IE where are lab results held for this
patient and so on.
Since each of these is a question whcih we routinely ask our existing
systems, it cannot be hard to automate - one might as a thought
experiment use SendKeys to bombard the system with keyrrpesses as if one
were a user, but surely the companies providing them can do better.
As I understand it this is how one makes a reservation on an aircraft,
when they are flying; how United Parcels gained a specific business
advantage from use of the WWW, and so on.
> and you need to support that interface when any of
> those back-ends is upgraded or replaced.
You don't though, see above. It becomes a condition of entry.
> Creates a nightmare maintenance
> headache. Better to define a new system that others export data to or
> migrate to.
On this I can say that I have been involved in that, more than once, and
it has not worked.
> The approach outlined would result in a piecemeal system, that wouldn't
> be useful for something like patient data. As it would always be bailing
> out to the common feature set - read text or image for this patient.
No. Not particularly useful. Not to the users of the data.
Images - we already have PACS, including an Open SOurce one from
Geneva.
> > We have the example of the Internet before us, we know how these large
> > tasks should be attempted.
> Depends what criteria you place on it. The really large systems on the
> Internet that handle these kinds of user volumes are often proprietary
> (think GMail). Or inherently quite simple (DNS).
I meant The Internet. Not individual things on it, the whole thing.
> > The SCR is not a tool I expect to find useful even when it works, and I
> > do not think we have the capacity to make its administration honest.
>
> But if you provide the functionality via different back end systems, you
> still have the same basic problems to solve you just have to solve them
> repeatedly rather than once.
The SCR does not provide any useful functionality at present.
> So the someone unauthorised might see my medical records problem exists.
> The scope of it is limited because the number of people who can see my
> medical records is largely restricted to people who know how to access
> your computer system. Now no matter how you remove this restriction, it
> won't solve the issue that when more people can access my medical
> record, there is more scope for it to be done in a malicious fashion.
Ross Anderson's view on aggregation is one which I share.
> One might argue there are difference of degree in the risks simply
> because of the numbers. But ultimately I suspect you can't get the
> advantages without those risks.
--
A
--
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html