Jon David Patrick wrote: > My motivation for using EMF is to bring into the foreground the range of > issues that "electronic" introduces to its management and manipulation. > Following this line of argument and Tim's point about images the F should > stand for Folder, so EMF is Electronic Medical Folder.
But a folder is a bit of bent cardboard... and X-rays are kept in envelopes. I remain unconvinced that there is anything wrong with the term "medical record" or "health record", electronic or otherwise. > I can understand Richard's frustration with archetypes and their slow > arrival but I don't think that is the result of trying to get at the > fundamental aspects of the "system" to be modelled but rather it is an > attempt to model a very large volume of detail, so that they are caught in > the trees without seeing the forest. They seem to be developing a system for precisely and formally describing the cellular structure of the veins on the back of the leaves on the trees in the forest. It is a lengthy process... > I understand that "the medical record" is a standard term that is used to > represent a collection of diverse information and has an acceptance that > doesn't requires altering. However in the electronic world many things have > to change for us to get the modelliing to a point that is reliable for the > DIVERSE range of purposes the "record" serves. > To return to Richard's point and the need for further modelling. In working > with hospitals we have arrived at a 4 class model of "physician" roles. > "Physician" being a surrogate for the collection of people and > occupations that surround that function. These roles help us better define > the functions that an information system needs to serve and defines the > services that should be provided. The roles and their processing needs > are; > Clinician - someone working at the point of care - needs are EMF retrieval > Researcher - doing analysis of data for improving care - needs are > aggregation of data across EMFs > Administrator - doing analysis for the daily operations of the > organisation - needs aggregation of data across EMFs > Auditor - doing checking against defined standards - mostly aggregation but > also retrieval in special circumstances, plus certain types of medical > knowledge. > > This analysis now tells us that a sophisticated system for performing > "aggregation" is the primary need of a medical information system - not > "retrieval" as is currently the case. Not sure that aggregation is the primary requirement, but as a public health person and epidemiologist I couldn't agree more that "aggregation" is vital and largely missing from existing clinical systems, and/or largely overlooked in their implementation and deployment. "Slap in some commercial reporting software designed for accountants and she'll be right" is the usual approach. It rarely is. I constantly see hospital clinical systems which cost hundreds of millions of dollars to deploy being installed with very little thought given to how to actually record what is wrong with patients in a consistent and analysable manner, let alone to tools (and expertise and/or training) for aggregate analysis. > Of course one physician can fill all these roles, even almost concurrently, > and there may be other roles people wish to define for their own purposes. Most clinicians (of all types) are actually interested in aggregate analysis - either in clinical epidemiology and quality assurance, and/or in the population health context of the health problems which beset the patients they see. When we first approached ED clinicians to set up he system described here (as it was 2 years ago, it has advanced since then): http://www.biomedcentral.com/1471-2458/5/141 - I expected disinterest or hostility. In fact, almost all ED physicians are really interested in and engage with population health issues - they are just as interested in systematic solutions to many of the recurrent and common health problems and injuries that they see as they are in optimising the care of individual patients. The same applies for general practice, is it not so? However, clinicians are poorly served by information tools in this respect, and there is also a lack of engagement between public health people and clinicians. But these things are changing, slowly. > However these are the 4 roles we have come up with for the purpose of > generalising the description of the information system we have to model. > Our model has a number of other characteristics to it which I will publish > to the list when it seems to be in reasonable shape. I'm sure you'll get valuable constructive criticism from this list, as well as broadening it from a hospital perspective to one which embraces primary and community care - the issues are very similar, of course. Tim C > Quoting Tim Churches <[EMAIL PROTECTED]>: > >> 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. >> >> It is just customary usage to refer to it as a record, even though it >> does indeed comprise many different parts. >> >> WordNet (for others: see http://wordnet.princeton.edu/ ) has 8 different >> senses for "record" as a noun: >> >> Meaning #1: anything (such as a document or a phonograph record or a >> photograph) providing permanent evidence of or information about past >> events >> >> Meaning #2: the number of wins versus losses and ties a team has had >> >> Meaning #3: an extreme attainment; the best (or worst) performance ever >> attested (as in a sport) >> >> Meaning #4: sound recording consisting of a disc with continuous >> grooves; formerly used to reproduce music by rotating while a phonograph >> needle tracked in the grooves >> Synonyms: phonograph record, phonograph recording, disk, disc, platter >> >> Meaning #5: the sum of recognized accomplishments >> Synonym: track record >> >> Meaning #6: a list of crimes for which an accused person has been >> previously convicted >> Synonym: criminal record >> >> Meaning #7: a compilation of the known facts regarding something or >> someone >> Synonyms: recordbook, book >> >> Meaning #8: a document that can serve as legal evidence of a transaction >> But you'll still see signs in hospitals pointing to the Medical records >> Dept and so on. And "record" does reflect its function: as a record >> >> >> Senses 31 and #8 are clearly the ones intended by the term "medical >> record". I'm not sure that the fact that the record is, these days, a >> composite entity means that record is no longer an appropriate term. >> >> "File" seems like an anachronism, however. Electronic medical records >> are more likely to be stored as software object instances and/or in >> tables or "relation" in a relational database. Similarly, "form" implies >> a paper or computerised template for specifying and constraining data >> items to be collected, which is fine, but a digitised X-ray image or >> digitised ECG or photograph doesn't seem to fit that paradigm at all but >> is equally part of the medical record. >> >>> 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. >> The Scots call it an "emergency medical summary", which seems >> appropriate, provided that you remember to roll your Rs when saying it. >> >>> 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. >> But it won't be a file, nor will it be just forms. I don't see any >> problem with "record", personally, but perhaps some other noun can be >> found. And an appropriate collective noun. A pride of lions, a flock of >> sheep, a ? of electronic medical records/forms/files? >> >> Tim C >> >>> 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. >>> > > > ---------------------------------------------------------------- > 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
