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
