On Thu, 2007-04-05 at 05:52 +1000, 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. > 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 didn't get it working at a basic level, and kept it working with continous automatic testing. > 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. > which is what SQL is supposed to solve, with it's flexible query language and query unifying table views.
> 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. > 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. > 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]>: > > > 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
