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
