On 03/04/2007, at 8:47 PM, Richard Hosking wrote:
I reckon there has been too much focus on trying to model the
nature of medical data in various ways.
Not too much, it is a matter of coming up with the simplest congruent
coding system to represent a medical proposition.
We should develop a platform for an EMR/whatever,
the most elegant platform would be imho ruby on rails,
including the financial side
Horst has paid for that one
so that it can be a viable alternative for practices.
after the lecture from TimC about monopolies, alternative frameworks
are likely healthy.
Then various data concepts can be modelled and tested using
schemas as appropriate in the real world.
Sure, frameworks should be extractions of real working systems...else
you get
At the moment there is lots of work going on at an abstract level
(eg openEHR) but no implementations.
From this vantage point, the above is not true on both counts.
How are you going with the rails stuff?
Kuang
R
kuang oon wrote:
Hi Patrick,
You are right if you define "record" in the computer
database sense. Historically, the medical record predates the
computer era and
the word "record" has the meaning of "a permanent account of the
patient's history". As for EMR , it sits well with medicos for
this historical context.
Cheers
Kuang
Docle - more speed, less haze, same meaning as English.
On 03/04/2007, at 6:15 PM, Jon David Patrick wrote:
Tim's definition of an EMR has tempted my to bring out one of my pet
prejudices against the misuse of words. Given the nature of a
record is
normally singular and an instance I find it unusual and
contradictory to
have the file of a patient consisting of many different
"records" to be
called a "record". It is far more an electronic medical file/
forms = EMF.
However i think that using the best/most approximate language is
not just
about a formality - it is also about grasping the most
fundamental nature
of the problem definition and grounding it in the most
comprehensive and
semantically deep model one can muster. At the moment the work
of various
bodies at building an "EMR" mistakenly view the task as creating
a unified
entity which in fact it is not. Their work is about coalescing a
range of
very varied content collected in different ways, stored in
different ways
and used for different purposes. However the Scottish exercise for
building the emergency medical record EMR is legitimately named
being a
unified record aimed at a small strongly coherent collection of
content
for a dedicated purpose and it has been a success for that clear
mindedness.
So if we are going to pursue the nirvana of an opensource
general practice
information system lets give it a more precise name, the EMF,
so that we
build what we actually want.
cheers
jon
--
Jon Patrick
Chair of Language Technology
Australian R&D Centre for Health Informatics
School of Information Technologies
University of Sydney
Quoting Tim Churches <[EMAIL PROTECTED]>:
John Johnston wrote:
Tim,
I agree with your summation here. Those are pretty precisely the
economics
for the build of what is required. Outstanding components, of
course,
re Patient, Product and Provider identifiers so that the business
models can be evolved. Perhaps we could start with a philanthropic
health fund and we will use their identifiers to make a start for
the Patient, and their identifiers for Providers, and we will just
make a decision about Product identifiers from preliminary
guidelines
coming out of NEHTA....
In this context "EMR" is taken to mean a clinical information
system
operating within teh scope fo a single practice or clinic (could
be a
large group practice with multiple sites). Thus could use local
identifiers for patients and health profressionals, but
obviously should
be designed with other identifiers with wider scope, such are
regional
or area public-sector health service MRNs, statewide unique patient
identifiers and even teh mooted NEHTA unique patient identifer,
and/or
the Australia (Smart)Card, and good old Medicare numbers etc.
An esemble
of identifiers. Likewise for health professionals. Unique
identification
of pharmaceuticals is more problematic and that is the bit which is
missing-in-action.
and bingo all we then need is a sustainable
business model based around an annual contribution from consumers
(possibly) for the benefits they will derive.
A good model is the supported appliance model. Basically the
software
and database is installed (via a fully automated script) on a
pair of
redundant commodity (Linux) servers in each practice, and thus user
interaction with it is over the local network, is fast and is
immune
from Internet outages. But this local system is continuously
mirrored to
a support data centre via an Internet connection (at least while
that
connection is up, or intermittently for practices in rural and
remote
locations with poor Internet connectivity), and the remote data
centre
thus provides offsite back-up, disaster recovery and software
support
services (including remote upgrades etc). Money changes hands
for these
services. However the software itself is freely available under
an open
source license, and thus other data centres/support services
can use it
to offer competing services, and cluey practices can run their
own show
and support themselves if they wish. The software itself is under
guardianship of a non-profit foundation to which contributions
of money
(to pay for implementation of new features) or code (actual
implementation of new features or add-in modules) can be
donated for the
good of all. The foundation would need to be funded somehow, but
I dare
say at a cost of less than $1m per annum.
Capital outlay for each practice would be hardware only. No
software
costs. Software support costs as an optional ongoing service,
with a
market of providers to choose from.
Building a federated or centralised shared EHR on top of such
infrastructure would, of course, be entirely possible.
But a medications database is needed, and that's currently missing.
Tim C
-----Original Message-----
From: [EMAIL PROTECTED] on behalf of Tim Churches
Sent: Tue 4/3/2007 7:01 AM
To: General Practice Computing Group Talk
Cc:
Subject: [GPCG_TALK] Ultimate EMR
Well, that's its name. It is a new, open source, Web-based
EMR for
the
US market, based on Zope and Plone, which are intriguing
but probably
quite sound choices for infrastructure (uses an object
database, not
a
relational database - makes much sense for clinical data). See
http://www.uemr.com/index.html
Probably not usable as-is in the Oz setting, but yet another
demonstration that it *is* possible to create viable open
source
clinical apps with very modest investment. They mention
"four years
of
effort", probably by one to three people - thus around 10
person-years
of effort. That's around $1.5-2.0 million of investment.
Would be
money
well spent by a govt agency or even a private philanthropic
concern
in
the Australian setting (or even sponsorship by a private
health
insurance company - what better way to promote yourself but
to have
posters in GPs' waiting rooms say "the computer software
used by this
practice is proudly sponsored by...". No need to wait 4
years: half a
dozen smart people could do it in 12-18 months, with
increasingly
polished prototypes to show off and get active feedback at
monthly
intervals along the way. That's what Australian patients
and health
professionals deserve.
Tim C
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
John Johnston
Pen Computer Systems Pty Ltd
Level 6, The Barrington
10-14 Smith Street
Parramatta NSW 2150
Ph: (02) 9635 8955
Fax: (02) 9635 8966
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
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
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
