I agree that MIQUEST has been one of the most successful UK projects. 100%
of the credit belongs to David Markwell. MIQUEST is now a UK national
requirement for accreditation of GP systems.
It is based on a very simple model, in which each patient has any number of
journal entries, referrals and encounters. The model is simple and general,
enabling almost any GP system to map their records into it. The model is
similar to Archetypes and is described below in as short a space as possible
:-)
Patient - patient demographic details including name, address, identifiers,
date of birth, sex, GP and registration status. There are rules about which
items are available locally and which can be provided to remote enquirers to
protect patient confidentiality.
Journal - entries signified by a single clinical code (e.g. Read Code).
Each item includes code, GP responsible for entry, date of item (this could
be date of onset), date recorded, free text, up to 2 numeric values (e.g.
for BP), status (such as first or subsequent entry in episode) and a number
of optional fields. Every clinical code generates a separate journal entry.
Referral - including date of referral, referrer, specialist, specialty and
provider unit to whom referred and type (OP, IP, Emergency)
Encounter - including date, ID of GP or other professional, type (general,
night visit etc.) and location.
A full copy of the MIQUEST specification (137 pages and very detailed) can
be downloaded from
http://www.exeter.nhsia.nhs.uk/products/vaprod/miquest/miquest.asp. Most of
this is devoted to the mechanics of making remote enquiries on heterogeneous
GP systems, while preserving privacy. Enquiries are formulated in a special
health query language (HQL), based on SQL. Happy reading.
Tim Benson
> -----Original Message-----
> From: Dr Adrian Midgley [mailto:[EMAIL PROTECTED]]
> Sent: 14 April 2001 9:07
> To: Open Health list - Minoru
> Subject: Health Query Language: need an open one?
>
>
> 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/
>
>
