[log in to unmask],Net wrote at 10:28 on 04/10/98
about "EHR - is it logically possible?":
-----------------------------
Good stuff Mary, all of it.
I have a big search runing on my networks because I know I have
some stuff which covers specific this and I will post something on
this on teh web or here in due course.
>I've been thinking about the concept of the fully transportable
>Electronic Health Record, and there seem to be some problems.
Our existing systems are on the one hand too comlicated, on the
other too simple.
>I accept that the mention of new solutions and private financing of GP
>computing implies a single, new system - and the death (or sublimation)
>of *all* our present systems.. which again raises problems of current
>investment and information held in legacy systems..
Beg to differ. I think a few overarching systems can carry on using
the legacy stuff for ages, and as you pick out the problem of the
meaning of stored data depending upon its container - and also of
course on the person who recorded it - the latter being common to
all record systems whether paper or not, the former being
exacerbated in paper systems by forms and demonstrated well by the
HA ad hoc survey of your choice<g>
>1.Extraction and insertion of the EHR.
>2. How can the EHR be legally authenticated?
>3.Completeness of information
>4. Legacy data.
>5.Quality of data.
>
>1.Extraction and insertion of the EHR.
>I can see that it might be possible to extract a complete EHR into an
>HTML format from almost any system - but is it possible to *insert* an
Mary, HTML is a markup language for displaying information, David
Markwell explains this better than I could, and might be worth
paying to do so at a conference or meeting on this for PCG IT Leads?
XML is what we need, and is available and can be brought in steadily
and elaborated as needed.
Where you have a tag like <BP 140/80> the software reding it can
either format it and show it on screen (indent a little, put a colon
up after BP and then show the figures or else it can do data
processing on it knowing it is a BP, and not any other collection of
figures.
>EHR into any existing or new but non-identical clinical system at the
>new practice?
TextBase will do that. Good enough for reading. Better for
reinserting into the legacy database than retyoing it from paper.
>If you can insert the EHR into a different, existing system , what
>happens to your coded data?
>(background - we had a conversion from Read 4 to Read 5 in 1994. I
>analysed the conversion table, and the problem is generic - *what do
you
>do with coded data when the new coding set does not contain a Term
which
>is identical in meaning and position to the coded data in the old set*?
>There is *No Way* a meaningful conversion can be guaranteed, even with
>human intervention.
Concur. There is an ISO set of identifiers which are 6 digit
numbers for coding systems.
See Hubris for details of some of it but imagine coding structures
like
Read2.5 G2 Hypertensive Disease a practice
ICD9 zz Something almost but not quite the same. a hospital
Read2.4 G? Hypertensive disease a different practice
Snomed ?? histological stuff the lab
and store the codes, with their identifiers, and the rubric the
person picking the code picked, and then work with that. Call it
metacoding if you want to get fancy about it.
>I suppose the implication is that, by this time, all systems will be
>using Read Code version 3 (assuming it passes the scrutiny.. which I
>think it should) and the problems of implementation and use are not
>insurmountable.
The problems of implementation into hospitals are at present
insurmountable. (IMHO)
>If we're not all using the same set of codes for all purposes
(including
>the same drug dicionary..) , will transfer of an uncorrupted EHR be
>possible?
Yes, above.
>2. How can the EHR be legally authenticated?
I don't think it needs to be as authenticated as it is.
At present we get a printout, which could clearly be edited or
counterfeited easily.
Relax on that one. (personal opinion at variance with most I think)
>At the moment, my system maintains a record of which user entered which
>bit of information, and the audit trail records any alterations.
>*Is* the audit trail transferable, and if it is, how will it be
possible
>to authenticate the original entry, when the individual who made it is
>not recorded in the computer security system?
Paper notes are signed...sometimes...and one could in principle
track back through the route the notes have followed to get to us.
Apply the same sort of thing to electronic wandering notes.
How often will we need to refresh the notes from the original? Not
often, so leave it to people to do that when needed, and concentrate
the cleverness of programming on making the machines help us do
medicine. more difficult, more useful, and less well understood by
the admindroids who therefore need their hands hel by the
professions on it.
>Will the system in the future have to maintain records of *everyone*
who
>is entitled to enter (or view) data in the whole of the NHS extended
>family? (as well, of course, as everyone who has retired or left..
>presumably with some mechanism to remove lapsed rights.. but perhaps
>thatt belongs to a separate thread on the EHR and Confidentiality?;->>)
>
>3.Completeness of information
>a lot of GPs don't actually use it in consultation.
Don't rely on what you see from GPASS users (old version)
>*Is the current EHR sufficiently complete to be used as a basis for a
>total record*?
Not _as_ a total record, but I think it is sufficiently complete to
be used as the base on which to build or hang one.
Some of the more obvious changes needed would be to provide GP
clinical/administrative systems which meet the needs or wishes of
the GPs/Practices involved. For instance if a practice doesn't have
one at present, you could make a reasonable assumption that it is
either because they can't afford it...in which case th only sensible
solution is to give them one and assure them they don't have to pay
to maintain it...
Or because although they could afford one (eg a network and a copy
of Paul Rubner's program, which still looks fairly good nowadays)
none of the available _particularly currently approved_ ones do
anything they really want done or do it in a way they like.
The only sensible solution there is to find a system that does it
like they like, but a useful step there is to buy them the network
and the PCs, and give them a copy of MS Office and an e-mail client
and so on and let them get on with office stuff.
>4. Legacy data.
>I am using this for all past data which has not yet been entered.
>We'd like to go paperless - but if there is a large MRE , the task of
>entering possibly significant data is daunting.
Probably a term better used for database info in old systems I
think, I would stick to "old paper records" or "the OPR" for such
stuff. Is it really _daunting_?
Can we get some figures from those who have done it? How long does
it actually take to scan in a weeded and summarised OPR from its MRE
into an image database? The limiting factor is probably the speed
at which a clerk can flatten out and feed sheets of paper into a
scanner. That seems to be about 2 per minute for an old PaperPort,
but there are faster ones, and I can imagine a PCG buying one, and
sending round a crew to do it in a practice.
I tend to reduce OPRs by about 10-50% when I read them, depending on
how much is lab results, old consent to PMA forms, handwritten
precursors of typed discharge summaries and so on.
>but I
>can't see that we have much hope of entering the entire past record -
>and having it legally acceptable - or even safe!
Let us price it rather than hope for it.
>5.Quality of data.
>
>I think what the CHDGP is showing is that the quality and/or
consistancy
>of data held in computers is very variable - and I'd suggest that the
>use of tools such as MIQUEST to produce pooled data to assess Health
>Care Needs is therefore, at present, limited - or even dangerous.
Agree. But a bit better than what has gone before. The admindroids
demanding info need to be informed by GPs who use computers what the
limits to usefulness oif the answers to the questions they ask are.
Words like "ignorance", "stupidity" and "bloody minded
intransigence" may need to be introduced into conversations from
time to time, when simple statistics and common sense fail to carry
the meaning across.
>If a tool such as MIQUEST (which searches on specified codes) is to be
>useful, there has to be a knowledge of *what* codes have been used to
>monitor a condition, even if you can be sure that the condition is
>monitored *using the computer* in the first place!
Iterate. It takes several iterations to get the data clean, but
each iteration makes a little improvement.
Well-chosen topics to iterate, together with a sensible appreciation
of what is possible, will produce small clinical improveents each
time the iteration cycles.
>In addition, there may be a problem as to the data items checked - for
>instance, in diabetes mellitus, which codes do *you* use for retinal
>checks? why these codes? and how do you record absence of diabetic
>retinopathy? (I haven't looked it up for the 4byte set..;-<<)
> what will
>happen when a EHR of unknown provenance is inserted into *your*
>database?
Show it in grey.
Don't search it.
As we get XML defined minimum dataset items shared across the PCG
these will come across, and then can be trusted well enough for
returns to the admindroids, although we might want to apply an
accelarated aging to those data fields (IE an examination of an
organ/system done yesterday is bright and clear on the record, done
5 years ago it is dim, but if it was done elsewhere it starts off by
being dimmish)
>I'm just trying to get a discussion going, so I'll stop at that.. for
>the time being.
>PS I feel like the person who, when asked directions by a traveller,
>said "If that's where you want to go, sir, I wouldn't start from here
if
>I was you!"
95% concordant with that view.
--- OffRoad 1.9r registered to Adrian Midgley
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
