Richard Hosking wrote:
Who are the customers? I think GPs remain the primary customer, but the
business case remains weak. I have now used probably the top 3 software
programs in Australia - I am still not convinced that fully electronic
records are good for my business (they take longer) . If money was the
only consideratiuon I would go back to paper. They *possibly* reduce
medicolegal risk but other factors such as the behaviour of my fellow
doctors in a group practice is a greater determinant of risk, and it is
by no means eliminated.
This is an important observation - that fully electronic health records
in a GP setting take longer to record. You're not the only one to make
that observation. It seems to me that a fundamental question remains
unresolved: are electronic health records in primary care settings
intrinsically slower than written records, or is the apparent slowness
due to unimaginatively (and/or unscientifically) designed software, or
is it because there is a tendency to record more information in more
detail in electronic medical record systems?
There are remarkably few studies addressing these question, at least of
which I am aware, and virtually no published research into better user
interfaces for primary care electronic medical records systems. That
seems to be a rather large gap. I know of at least one nascent academic
consortium comprising a school of computer science and a school of
health sciences which is ready and raring to get stuck into solid R&D in
electronic medical records user interface design, in particular using
natural language processing to allow tight integration with clinical
terminologies such as SNOMED CT (without which many of the decision
support and safety benefits of EHRs are just pipe dreams). And they are
keen to release practical open source implementations of the
technologies developed as part fo the research. If just a few of the
many tens of millions dollars spent on HealthConnect to date could have
been (or rather, could be) directed to such R&D, then we might get
somewhere. Without such research, the shared EHR cart is in grave danger
of being left without a primary care electronic medical records horse to
pull it along, because, as Richard points out, with current system it
just doesn't pay for GPs to record everything (or all teh important
things) in electronic form. Or at best, Australian vendors of GP
information systems will have to license such technology at great
expense from foreign firms (such as Health Language Inc - see
http://www.healthlanguage.com/ ). Kuangie has been working on such
things, but we need more than one person working in their garage on this
sort of stuff (and due to Kuangie's approach to patents and licensing,
his stuff is destined, I fear, to remain the work of an individual in
his garage).
Governments and public health should be considerered as a customer - the
business case for them is much stronger. Lets bite the bullet and get
past all the politics - a national networked electronic record could
have enormous public health and financial benefits - probably greater
than any other single public health measure currently proposed.
I think we should be seeking "requirements" from Govt and public health
bodies re communication, data mining etc up front
As a public health person, I can't help but agree that there is a strong
business case for public health benefits from wider and better use of
primary care electronic medical records. However, I am unconvinced that
spending huge amounts of money on 'a national networked electronic
record' is the optimal way of acheiving these benefits. Much better to
plug GP's information systems into population-based "registers" whch
ensure that people don't fall through the cracks when it comes to
primary (and secondary) prevention. Pap smear and mammography registers
are well known examples of these, but why don't we have population-based
metabolic syndrome registers, or childhood obesity registers? The number
of data items needed for such registers is not onerous - 10 or 20 data
ietms for a metabolic syndrome register would suffice. Everyone talks
about patients needing to take responsibility for their own health, but
realistically people need active assistance and persistent encouragement
to do this. Such a register would start by checking that every every
adult over 40 years of age (or perhaps younger) has had their weight,
waist and BP checked recently, and where indicted, their serum lipids -
no matter which GP, community health centre or other health care
provider they might have attended. If they haven't, they are sent
letters encouraging them to have these things checked, in the same way
that all women in the population over 50 years of age are invited to
attend for screening mammograms (in most states and territories). In
just a few years we would have very, very good population-based
information about risk factors that can not only be used to encourage
individuals ona person-by-person basis, but also motivate and provide
the business cases for the serious redesign of society and the built
environment which is needed to get us out of our current
exercise/diet/weight downwards (or upwards?) spiral (to mention just one
health set of health issues - there are many others). It is easy to
extend these ideas into other areas of primary and secondary prevention,
as well as quality assurance and safety. And it is eminently possible to
set up such registers while maintaining privacy - see for example
http://www.biomedcentral.com/1471-2288/3/1 With a common infrastructure
and set of interfaces for population-based registers, the marginal cost
of setting up and running yet another population-based register becomes
rather small. Finally, from a research and epidemiological
point-of-view, it is MUCH more valuable to reliably collect a small
number of well-defined parameters from everyone, or very nearly everyone
(the population-based register model), than to less reliably collect a
much wider range of poorly defined data items on a smaller,
self-selected proportion of the population (the shared community EHR model).
I really should write up the foregoing ideas as a discussion paper for a
peer-reviewed journal. If anyone on this list is interested in being a
co-author on such a paper, then feel free to contact me off-list
(provided that you are willing to contribute to the writing or editing
of the paper, of course).
Tim C
David More wrote:
Hi Horst,
I think you mis-understand the purpose of the IBM documents and fail
to appreciate the work was done over 8 years ago when the now
available tools and approaches were still evolving. (Think of the
level of web penetration then and now!)
What we did in those reports was identify, describe in some detail,
place a priority on and try to group logically the functions required
to best support running a general practice.
It was intended to be technology neutral in all senses - to permit
developers to adopt what ever platforms and tools they desired to
create an implementation. It was never intended to be a developers
'cook book' and to translate directly to a system - there is an
intervening technical design step - and that's the one we expected the
developers to do. We did however indicate areas of data etc that
needed to be managed as I recall.
I believe, on the basis of many comments over the years from GPs, we
got it close to right at the level we were working. It would be good
if talent's such as your good self could undertake the next steps -
especially in the open-source environment and finally bring it to
fruition. It still seems to me that there are aspects of the
functionality we suggested that have not been achieved - but I may not
be familiar with the very latest. My latest look a few years ago
certainly showed there was not much implemented we had not identifed.
With modern development techniques it should be easier now that it
looked then.
Cheers
David
----
Dr David G More MB, PhD, FACHI
Phone +61-2-9438-2851 Fax +61-2-9906-7038
Skype Username : davidgmore
E-mail: [EMAIL PROTECTED]
On Thu, 29 Dec 2005 22:57:13 +1100, Horst Herb wrote:
On Thu, 29 Dec 2005 22:43, David More wrote:
Could you explain just what you mean for those of us who are a bit
slow? I,
for one, have no idea what you are saying....
He is saying the same thing I said when it was published: little
substance.
Nothing new that wasn't known before, very expensive way to put that on
paper, but the extra mile that would have made it useful (namely
detailed
implementation specs suitable for a real life program) was not done -
at all.
What we ended up with is a document that can be useful as
introduction to
software developers completely agnostic of the medical domain, but is
fairly
useless to those already in this business and familiar with our domain.
Meaning it is fairly useless exactly to those (only) people currently
actually writing medical software.
If you want to end up with a functional computer program, you have to
create
specs that lend themselves to implementation in software - and best
done in a
way that can create some of the boring software bits automatically
from the
specs (e.g. specs in UML). Not just the bird's eye view but the nitty
gritty
details.
Horst
__________ NOD32 1.1343 (20051228) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com
------------------------------------------------------------------------
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
