One of the fairly hopeful UK projects was to produce a means by
which a central body could ask the same question of a number of
general practices each using different software,
and receive answers which could be aggrgated meaningfully.
It was referred to as MIQUEST and ran on or implied Health
Query Language, obviously a superset and extension of SQL.
The software included modules that each supplier was supposed
to (and I think almost all have in some way) implement in their own
program, and a central set of programs of which I know little.
Confidentiality etc
------------------------
Two varieties of query were defined - the local one whcih would
report names, and the distant one which was intended to remove
_all_ patient identifiying data before passing the aggregated result
to the enquirer.
Usage
--------
Supposing you were trying to run a health service, and wished to
make use of actual data - numbers of patients with coronary heart
disease who had not had bypass surgery for instance - in
planning future delivery. (Number of beds to provide in the new
cardiac surgery unit, by year into the future for instance)
You would use the central bit to compose a question:-
"how many people on your list have a diagnosis of IHD, and not a
summary item of xoronary bypass surgery? Report by 5 year age-
sex groups."
And get back an answer like
0 0 0 0 0 0 0 1 0 2 1 3 5 2 1 0 ...
from each practice. They get automatically aggregated, and you
then know how many beds to expect to need over the next few
years...in conjunction with other information, of course. (You still
can''t afford them and should have started 5 years ago, but that is
a problem allegedly insoluble by technology and a digression)
If you were doing this by paper queries then apart from it requiring
people in 75 Practices to do actual work finding out, the usual
delay of a month while you wait for the next practice meeting and
so on, but you would risk fatigue of the practices if you then
decided that it woudl be nice to know how many of those people
were _not_ on (Aspirin OR Clopidogrel OR Dipyrimidazole OR
Warfarin) AND didn't have a specific reason not to be recorded,
and the same for the statin drugs.
(For non-medics, these drugs make you less likely to have a heart
attack, or to need surgery on your coronary arteries, but the altter
group are expensive, thus being some cause for interest among
both doctors aiming for the best results across an area, and finace
droids trying to work out how to pay for it)
Since we do not have general agreement that we will all, in a short
time, standardise on a single one of the candidate program suites
from the open source projects, we should consider whether we
need a separate open recreation of MIQUEST; a political effort to
persuade the NHS to give it to the world; whether HL7 or some
other existing mechanism will transfer the relevant aggregated
information (I don't think so, but I don't know as much about HL7
as I should)
David Markwell and his company wrote MIQUEST/HQL, in 1994!
www.clinical-info.co.uk
Demonstrators have been available at least in the past from there,
and it is likely that the optimal solution is to build MIQUEST into
emerging programs...or at least leave a space it would fit into.
Some of the projects are more directed toward analysis and
extraction of results (we know, Andrew) and some are more
oriented to workflow in the practice and the day by day work in the
consulting room and at the front desk. Nothing wrong with any of
that, since they all started to scratch particular itches, but there
are things to do to make complete solutions, and genericising
those, rather than writing individual solutions would be of benefit
to anyone who is part of a larger whole.
On a general note, as my thoughts have turned toward the
distributed medical record and the distributed medical service, by
way of writing reporting additions for the stuff I use in the Practice,
I have more and more seen an EPR as something that is equipped
to answer certain questions, a large number of such which is
growing steadily and only some of which can be predicted in detail
by the original author.
I mean the core or kernel, rather than the whole thing, and
exposing the ability of the core to answer questions such as:-
Is this woman fertile?
Has a claim for providing contraceptive services been made
dated between {date 1} AND {date 2}
Does this patient have coronary heart disease?
and see above
Is this patient believed _not_ to have coronary heart disease?
Has the blood pressure been measured and found in range in the
last smallestof(function(age), function(disease,"G....") years?
I think both helps the user from day to day, helps writers of
additional programs to run alongside, may help other clinciains in
other places to manage the patient, and helps the group the
owners are part of.
--
Adrian Midgley
Exeter
http://www.swis.net/midgley/
