healthy4u

Draft Patient Rights Statement and Informed Consent on Use of HIT

Health IT has been nearly universally touted as "improving the quality of medical care." That implies that HIT also affects outcomes of care, and that if it is defective or malfunctions, it can reduce the quality of medical care and contribute to poor outcomes. A virtual medical tool (i.e., a medical tool that happens to involve computers) that can impact the quality of care and outcomes either positively or adversely seems to me to be a very potent device. I also believe the regulatory definition of "medical device" needs updating; it may have become obsolete with the galloping advances in technology over the past decade or two. Patients currently are subject to the effects upon their care of electronic medical devices known collectively as "clinical IT" (electronic health records, computerized physician order entry, clinical decision support, clinical data repositories, etc.), but are not informed of the nature of this IT nor its possible adverse effects on their care. The consent forms they do sign are, therefore, incomplete. I am proposing a "Patient Rights Statement and Informed Consent on Use of Clinical IT Devices" be required at healthcare organizations using this technology. Here is a draft of such a consent. Note that this draft is a bit tongue in cheek, but not entirely so. There is nothing nonfactual about it: <blockquote style="color: rgb(255, 0, 0);">Patient Rights Statement and Informed Consent on Use of Clinical IT Devices I, ___________, consent to treatment at Acme General Hospital. I understand my rights to the very best care Acme General can provide, and understand that Acme General has taken every feasible step to assure my safety and comfort. I understand that my treatment will be modulated and advised by my doctors' and nurses' interactions with clinical devices still under development in an exploratory fashion known as "electronic health records systems", "clinician order entry systems", "clinical decision support systems" and other computer systems, hereafter "clinical IT devices." I understand that said clinical IT devices are not subject to federal or state evaluation, regulation or approval, as are the drugs I take and the "physical" medical devices that may be used in my care (such as catheters and defibrillators), and were designed by for profit IT companies whose primary leaders and developers lack clinical expertise. I further understand that these clinical IT devices, while believed to be benign and helpful, have never been rigorously and scientifically proven to be safe and effective. I understand that the literature is conflicting on this point, and that patients have been documented to have been harmed or nearly harmed by design problems, defects and malfunctions in these clinical IT devices. I understand the vendor of the clinical IT devices in use at Acme General has a contract with Acme General Hospital that forbids Acme General and its employees and representatives from sharing known defects about the clinical IT devices with other organizations. I also understand that there are currently ____ clinical IT device defects known at Acme General as reported by its staff. Of these defects, ___% fall into the category of affecting revenue, ___ % fall into the category of affecting clinician work efficiency, and ___ % fall into the category of affecting patient safety and outcomes. I understand that of these known defects, ___ % fall into Class 1, "likely to cause patient harm in short term if uncorrected", ___% fall into Class 2, "may cause in patient harm in medium or long term", and ___% fall into Class 3, "not likely to cause patient harm, but may affect operations." I understand the vendor of the clinical IT devices in use at Acme General have granted Acme General 75,000 shares of their stock, and are using Acme General to refine these clinical IT devices for sale to other healthcare organizations and to other clinical IT initiatives in the U.S. and overseas. I also understand the vendors of these clinical IT devices have promised Acme General these defects will be remediated by ______ (date). Finally, I understand that use of these clinical IT devices may cause user fatigue and cognitive overload in clinical users after prolonged exposure, especially if not well designed, making the clinicians more liable to commit medical error. I, however, also understand, since these clinical personnel are "learned intermediaries", that if I suffer injury or die as a result of a clinical IT device problem, the vendor of the clinical IT device is immune from liability. The liability will fall upon the doctors and nurses using it, and upon Acme General. I understand that if I do not consent to use of these clinical IT devices by hospital clinicians during my care, I will be treated by clinicians using paper charts and forms to manage my information, which carries risk but is a proven technology in widespread use in medicine to record detailed clinical information over approximately the past century<a href="http://www.ipst.gatech.edu/amp/collection/museum_invention_paper.htm"></a>. Signed, ________________ (patient name) _________ (date) </blockquote> -- SS

Draft Patient Rights Statement and Informed Consent on Use of HIT

Health IT has been nearly universally touted as "improving the quality of medical care." That implies that HIT also affects outco...

Đọc thêm »

Health IT Project Success and Failure: Recommendations from Literature and an AMIA Workshop

A preprint article "Health IT Project Success and Failure: Recommendations from Literature and an AMIA Workshop" by Bonnie Kaplan and Kimberly D. Harris-Salamone (doi:10.1197/jamia.M2997) has just been published and made available in the Journal of the American Medical Informatics Association (<a href="http://www.jamia.org/">JAMIA</a>). It will appear in the May/June 2009 issue of JAMIA. [Addendum 1/2010: a link to a free PDF of the published article is <a href="http://jamia.bmj.com/content/16/3/291.full.pdf">here</a>.] There is a history to this publication, that summarizes the findings and recommendations of a surprisingly well attended workshop ironically named "<a href="http://www.ischool.drexel.edu/faculty/ssilverstein/failure_workshop_final_revised.doc">Avoiding The F-Word: IT Project Morbidity, Mortality, and Immortality</a>." The workshop was held at the 2006 national meeting of AMIA. Ten years ago, in early 1999 I started a website hosted on AOL, and called at that time "Medical Informatics and Leadership of Clinical Computing: Common Examples of Healthcare IT Failure." A historical version of the site (with a "politically corrected" title) is <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/medinformaticsmd/failurecases.htm">here</a>; the modern site is now <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/cases/">here</a>. The website was unique at the time and today, remarkably, remains nearly so (see <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/cases/content/documents/FINAL_Healthcare%20IT%20Failure_Oct_19_2006.ppt">this pdf poster</a> from AMIA's 2006 annual meeting). Yet I was to soon learn through correspondence about the website that these problems were common as well as international in scope. Healthcare IT failure was (and is) a somewhat "taboo" subject, in no small part because of contractual gag clauses on users and vendor lack of legal accountability for defects, as well as a striking overconfidence in computing and timidity about discussing organizational failure and IT mismanagement. Its open discussion has therefore been severely impaired and minimized. <div> </div><div>I pushed this topic hard among the Medical Informatics community, yet for years there was resistance to bringing this issue to the fore. I took significant "heat" for my views as well, making me somewhat of an outcast in my own professional community and <a href="http://hcrenewal.blogspot.com/2007/03/problems-found-in-uc-davis-emr-project.html">even to one of my former mentees.</a> This phenomenon may have been a combination of academic concerns about a topic that might dilute the field, preferential and understandable focus on successes, conflicts of interest, and other issues. <div> </div><div>[May 2009 addendum: the "taboo" nature of the subject of HIT difficulty and failure might in fact have been engineered by the HIT industry; see the article "<a href="http://www.washingtonpost.com/wp-dyn/content/article/2009/05/15/AR2009051503667.html?hpid=topnews">The Machinery Behind Healthcare Reform: How an Industry Lobby Scored a Swift, Unexpected Victory by Channeling Billions to Electronic Records</a>" by Robert O'Harrow, Jr., May 16, 2009, Washington Post -- ed.]</div><div> I, on the other hand, having been (pre-informatics fellowship) a Medical Review Officer in the medical department of a regional mass transit authority, and observing a fatal subway elevated accident related to drug abuse, was not going to back down. The accident was the worst in perhaps sixty years in Philadelphia, with hundreds of injuries and several deaths in part due to overriding of medical judgment by non-medical personnel on drug testing at time of union-demanded reinstatement of persons known to have problems. This was as a quid pro quo for labor contract approval. Worse, there were IT errors as well -- again with overriding of medical personnel, namely, me. I'd written a program on our departmental PC for random drug test date selection, but by MIS edict, use of that program was overridden in favor of some slop they authored for their machines - which "forgot" to enroll the operator behind the accident in random testing altogether. Months went by with no tests, and then at the time of the accident the operator's cocaine metabolite levels "blew the lid off the GCMS machine", according to the toxicologist performing the test. Having been informed by my earlier transit authority experience (and gaining some lessons in fortitude from the militant mass transit labor unions I had dealings with), I started the HIT difficulties website in late 1998-early 1999 after <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/cases/?loc=cases&sloc=clinical%20computing%20problems%20in%20ICU">watching ICU patients needlessly being put at risk</a> and the high risk <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/cases/?loc=cases&sloc=Cardiology%20story">Invasive Cardiology cath lab being disrupted</a> as CMIO at Christiana Care in Mr. Biden's home state. These problems were once again due to the ill-informed, capricious edicts of overempowered MIS leaders, sanctioned by equally ill-informed executive leadership. In fact, I quit that CMIO role, no longer being able to tolerate being a marginalized "Director of Workarounds to Dangerous Health IT Mismanagement" (as are many of today's CMIOs), unable by management caprice to make even the most basic of corrections to obvious and risky - and grossly negligent, perhaps even criminally negligent - design and implementation errors. With the exception of a period of time in pharmaceutical research IT from 2000-2003, I periodically sought additional case information on healthcare IT difficulties from colleagues via email and AMIA message board postings, but the results were lukewarm at best. I'd hoped upon returning to a focus on the healthcare provider IT sector in late 2003 that conditions in that sector would have improved. I was wrong. I continued to comment on these issues but with results similar to the past. However, as more informaticists became familiar with the organizational and clinician chaos that ill-conceived clinical IT and/or suboptimally managed electronic medical records projects were causing, a "critical mass" of interest and determination appeared to have been reached by early 2006. At my request my assigned research assistant at Drexel sent out the following message to a number of AMIA message boards, the clinical information systems (cis), ethical, legal and social (els), evaluation special interests (eval-sig) and the people and organizational issues (poi) workgroups. <blockquote style="font-family: arial;">From: poi-wg-bounces@mailman.amia.org [mailto:poi-wg-bounces@mailman.amia.org] On Behalf Of Yunan Chen Sent: February 27, 2006 8:46 AM To: cis-wg@mailman.amia.org; els-wg@mailman.amia.org; eval-sig@mailman.amia.org; poi-wg@mailman.amia.org Subject: [poi-wg] Healthcare IT failure cases Hello: My name is Yunan Chen and I am a research assistant for Dr. Scot Sliverstein in the Institute of Healthcare Informatics , College of Information Science & Technology at Drexel University . Currently, we are working on a project regarding Healthcare IT infrastructure failures. The purpose of our project is to investigate why Healthcare IT infrastructure may fail from a social- technologic perspective. We will collect cases published in scientific papers and newspapers, as well as unpublished stories by the Healthcare IT practitioners. Then, we will categorize these cases and build a casebase for future implementation guideline. We have already collected some cases which are listed in: http://home.aol.com/medinformaticsmd/failurecases.htm . The cases listed here were collected from 1998-2001. Now we hope to gather newly happened cases to enrich our collection. If you experienced or heard of any interesting story, please do not hesitate to write it down and send it to me. We hope to hear more from healthcare IT practitioners' hand-on experience. Any story is valuable to us. Any posting of the cases will be keep anonymous and we won't reveal identities of people or organizations . We will move the Healthcare IT failure cases webpage to Drexel University server later, so all your stories will be listed on that site. We will inform you once the new website is ready. If interested, please write back to me at: yunan.chen@ischool.drexel.edu . Comments and suggestions are welcome. I am looking forward to hearing back from you. Thanks very much. Yunan Chen Doctoral student & Research assistant Institute of Healthcare Informatics College of Information Science & Technology Drexel University</blockquote> It soon became apparent that a critical mass had been reached. A torrent of shared experiences of HIT difficulty in the various message boards appeared from all over the country and from other countries as well. Calls for a formal AMIA panel or workshop on this issue arose. This call was energetically supported by a heterogeneous and widespread group of informatics professionals. This momentum prompted the "<a href="http://www.ischool.drexel.edu/faculty/ssilverstein/failure_workshop_final_revised.doc">Avoiding The F-Word</a>" workshop to be collaboratively formulated in a wonderful volunteer effort led by former colleague Bonnie Kaplan at the Yale Center for Medical Informatics (where I'd completed my postdoc in medical informatics), and Kim Harris-Salamone, along with the AMIA workgroup members. Ten <a href="http://www.amia.org/mbrcenter/wg">AMIA workgroups</a> and over fifty HIT experts ultimately participated in the workshop. In Sept. 2006, before the workshop occurred, I wrote at "<a href="http://hcrenewal.blogspot.com/2006/09/holes-in-quest-to-enable-electronic_21.html">The holes in the quest to enable the electronic clinical trial ...</a>": <blockquote style="font-family: arial;">... I also think some answers to the question "Where are the holes in the quest to enable the electronic clinical trial?" will be found in an upcoming Nov. 2006 American Medical Informatics Association Annual Conference workshop on healthcare IT failure entitled "<a href="http://www.ischool.drexel.edu/faculty/ssilverstein/failure_workshop_final_revised.doc">Avoiding The F-Word: IT Project Morbidity, Mortality, and Immortality</a>", the first of its kind: <o:p></o:p> <blockquote><div class="MsoNormal">SESSION DESCRIPTION Recent studies of health care computer applications and the reported failures of well-known systems surprised the medical informatics community, leading to questions of how to increase the chances of IT systems success and the reduction of errors. Similar problems plague a variety of different systems, whether for institutions as a whole, for ancillary services, or for consumer health, and have done so for many years. Despite an accumulation of best practices research that has identified a series of success factors, some 40% of information technology developments in a variety of sectors are either abandoned or fail, while fewer than 40% of large systems purchased from vendors meet their goals. According to the recent CHAOS Report by The Standish Group, which surveyed failures of IT in general (not just in health care), only 34% of IT projects were considered truly successful. Similar numbers have been estimated for health care, and the number has unfortunately remained approximately the same for at least the last 25 years. While there have been some published reports of failures, removals, sabotage of systems, or how failures became successes or were otherwise redefined, there has been too little opportunity to learn from studies in which technology interventions resulted in null, negative, or disappointing results. The purpose of this session is to examine why this happens and what might be done to improve the situation, and to collaboratively develop a series of frameworks for various types of systems and healthcare settings to aid in implementation and evaluation. The session builds on a lively exchange by numerous members of a number of AMIA Working Groups concerning success and failure in medical informatics. The session will be devoted to better defining or characterizing "success" and "failure." From there, participants will break out into smaller groups to continue the discussion, develop a set of important issues, action items, and recommendations.<o:p></o:p></div></blockquote></blockquote> The report, now published, is filled with pearls such as these: <ul><li>With the US joining other countries in national efforts towards the many benefits health information technology use can bring for health care quality and savings, recent sobering reports recall the complexity and difficulties of implementing even smaller-scale systems. Despite best practice research identifying success factors for health information technology projects, a majority, in some sense, still fail. </li></ul><ul style="font-family: arial;"><li>With the United States Congress appropriating more than $20 billion for health information technology as part of the February, 2009 economic stimulus package, the US joined other countries in national efforts towards the many proven benefits such technology use can bring for health care quality and savings. Moreover, Medicare, along with private and commercial health plans, is implementing a new paradigm for paying for health care services in the US, known as Value-Based Purchasing (VBP), or pay for performance initiatives (P4P). These initiatives rely heavily on using electronic health records to provide clinical documentation that proves the value of their services. Tempering the fervor, though, are recent sobering reports that raise concerns about how the technology is designed and deployed.</li></ul><ul><li>Similar failure rates [to other types of IT] have been reported for health IT.(14, 15) Hospitals are among those organizations where delays and cancellations of software projects are endemic.(16) For years, problems have plagued the implementation of health IT applications, whether for ancillary services, for whole institutions, for regional or national systems, or for consumers. Today's problems are reminiscent of those analyzed since at least the 1970s in classic studies of hospital information and patient record systems.(17-19) In 1990, Dowling estimated that staff interfere or sabotage with "nearly half" of projects(20), while Heeks noted in 2006 that it is his "best estimate...that most HIS [health information systems] fail in some way."(15) Recent studies and newspaper accounts cite difficulties in a variety of health information technology applications. Over the years, in many countries, patterns of severe problems repeatedly have beset a variety of efforts: hospital information systems and electronic records(21-26); ambulance services(27, 28); community, regional, and national health information networks (28-33); public health systems (34, 35); patient education (36); and physician order entry.(18, 19, 37-41) </li></ul><ul style="font-family: arial;"><li>Yet, while there have been some published research reports of health care IT failures, unfortunately, there has been an absence of systematic and thoughtful publication of lessons learned from IT interventions where there have been null, negative, or disappointing outcomes.(27, 53) Despite calls for increased research, there are insufficient numbers of published research reports of health care IT failures, removals, sabotage of systems, or how failures became successes or were otherwise redefined. As in other sectors (69), IT-related failures in health care often are covered up, ignored, or rationalized, so mistakes are repeated.</li></ul><ul style="font-family: arial;"><li>Participants emphasized that communication and workflow issues add to project complexity. Health care requires collaboration, as does system implementation, yet there is difficulty in translating among specialties, stakeholders, clinicians, and implementers, sometimes to the point of a seeming "culture clash."</li></ul><ul style="font-family: arial;"><li>The workshop concluded with reports from break-out groups charged with discussing ideas for how AMIA could address health informatics failure. Break-out groups made suggestions concerning: research and publication, best practices, advocacy, education, certification, and databases and knowledge integration.</li></ul> The workshop findings concluded with these words of wisdom: <blockquote style="font-family: georgia;">Much has been learned about success and failure in IT implementation, but we need to understand more. There are legal issues when a system "fails," including just what constitutes "failure." There are social issues, ranging from how such failures affect various groups and health informatics as a whole (including possible policy and regulatory reactions), to the social aspects of what makes for a "successful" implementation. Finally there are ethical issues involved in evaluating system "success" or not sufficiently attending to previously-identified success factors and best practices.(24) Most "failures" are failures to properly apply managerial wisdom that has been substantiated by research and experience. Perhaps the worst aspect of failure is failure to learn from past experiences so that the same issues and problems are not perpetuated. </blockquote> While the workshop was a culmination of the kindling on this crucial topic I've been involved in since being overruled on <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/cases/?loc=cases&sloc=clinical%20computing%20problems%20in%20ICU">patient-endangering healthcare IT mismanagement</a>, I believe we as a society, and the HIT sector as a for-profit, entirely unregulated industry lacking accountability (the accountability rests on clinical end users, as in, in the courtroom in malpractice suits), are still very far from solutions to that final observation on failure to learn from history. The observations of this workshop are only made more acutely important by what I believe are ill advised, rushed plans to coerce US healthcare organizations and practitioners to adopt these evolving, arguably still-experimental virtual medical devices by 2014, or face penalties. -- SS</div></div>

Health IT Project Success and Failure: Recommendations from Literature and an AMIA Workshop

A preprint article " Health IT Project Success and Failure: Recommendations from Literature and an AMIA Workshop " by Bonnie Kapl...

Đọc thêm »

Tipping points

Ideas are everywhere, but how do we know which ones actually work? At Google, we put a lot of stock in both the wisdom of crowds — the idea that lots of people responding to a given question can collectively find the best answer — and the value of community. We believe that people working together can help one another through even the most difficult times. As we all navigate today's choppy economic waters, we'd like to put these beliefs into practice. That's why we created <a href="http://www.google.com/tipjar">Tip Jar</a> (www.google.com/tipjar), an experiment powered by <a href="http://googleappengine.blogspot.com/2008/09/introducing-google-moderator-on-app.html">Google Moderator</a> that we hope will help you discover the most effective ways to save money. There are lots of money-saving tips scattered across the web, but even if you found them, it would be hard to know which ones were worth trying. Tip Jar gathers tips in one place and invites people — i.e., you, me and everyone else — to rank them in order of usefulness and even add their own tips to the list. Over time, the best and most useful tips will rise to the top. So go ahead: <a href="http://www.google.com/tipjar">Take a Tip. Share a Tip</a>. We'll all be a little bit richer for it. Posted by Colby Ranger, Software Engineer

Tipping points

Ideas are everywhere, but how do we know which ones actually work? At Google, we put a lot of stock in both the wisdom of crowds — the idea ...

Đọc thêm »

Google Health: helping you better coordinate your care

We continue to learn a tremendous amount since <a href="http://googleblog.blogspot.com/2008/02/google-health-first-look.html">launching Google Health</a> in the spring of 2008. We're listening to feedback from users every day about their needs, and one issue we hear regularly is that people want help coordinating their care and the care of loved ones. They want the ability to share their medical records and personal health information with trusted family members, friends, and doctors in their care network. I can relate to this. Just a few years ago, my father suffered a minor heart attack and was sent to the ER. I arrived on the scene in a panic, and was asked what medications he was taking. To my surprise, I had no clue. If my father had a Google Health account, and had shared his profile with me, I would have been up-to-date on his current medications. I'm happy to announce today Google Health has addressed this issue with the release of a new "Share this profile" feature enabling Google Health users to invite others they trust (whether it's a family member, a trusted care network provider, friends, and/or a doctor) to view their medical records and personal health information. Log into Google Health, click on "Share this Profile," and type in the email address of the person with whom you'd like to share your profile. Google Health will send an email to them with a link to view your profile. The link will only work in connection with the email address of that person — your profile can't be accessed if the link is forwarded on. You can stop sharing at any time, and you can always see who has access to your information. Those who are viewing your profile can only see the profile you share — not any other one in your account. We've also built in some extra protections to make sure your health information stays safe, private, and under your control: <ul><li>The sharing link in the email expires after 30 days, but the sharing access itself does not expire — it will stay in place until the user decides to stop sharing</li><li>Viewers can only see — not edit — your Google Health profile</li><li>You can review a user activity report to see who has viewed your profile</li></ul><div><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjidmi9avwx4Z4aXx9tQSJVkTKBBXQ6dbJUG2UfhDXzitDa1Qo12_fpop-PoSCJI42hpT-9gh5_RuZ6iSZwOOs4Z6OMbaJ4t2ruB5SaUcVJ66F3_myA1gE_nu4K4CdSpU392DIZfQ_GtyNh/s1600-h/sharing.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5309409644659295042" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjidmi9avwx4Z4aXx9tQSJVkTKBBXQ6dbJUG2UfhDXzitDa1Qo12_fpop-PoSCJI42hpT-9gh5_RuZ6iSZwOOs4Z6OMbaJ4t2ruB5SaUcVJ66F3_myA1gE_nu4K4CdSpU392DIZfQ_GtyNh/s400/sharing.png" style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 230px;" /></a>For doctors and family members who are not yet online, we've also made it easier to share a hard copy of your information via our new printing feature. The wallet format prints a wallet-sized card that includes a user's medications, and allergies; the PDF format prints a letter-sized copy of a user's profile, including medications, allergies, conditions, and treatments. <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEicrv7vwEncDU_cBIiLtm5_l88z5czVOSfgxAAAzIIefQJMKpqLjHwkbV_NGu3nKxwBoODBWfT_uzukGhndqz2qB8Z7W3kIopQDV27peSqKugKFjGY2iMcxeMUeogHE9q2i_riAKfW9iBrh/s1600-h/print_idcard.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5309409648087240866" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEicrv7vwEncDU_cBIiLtm5_l88z5czVOSfgxAAAzIIefQJMKpqLjHwkbV_NGu3nKxwBoODBWfT_uzukGhndqz2qB8Z7W3kIopQDV27peSqKugKFjGY2iMcxeMUeogHE9q2i_riAKfW9iBrh/s400/print_idcard.png" style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 185px;" /></a>Finally, we've launched a new graphing feature that helps patients visualize their medical test information. This is great for, say, someone who has high cholesterol. They can use Google Health to enter their lab results on a monthly basis and see the trend over time. <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjByU6klWufGCsf06dKu5pB6ExTBN6Lsu6Q-TJ9bGfx_qE_tJ-1jYLtg5qrGf1OrHej4Lq33NfJAP0Ep-8HuwwJQSlPy8SgCCbCxAkFPsMoOVcBZzEPPSmod3JSXBKBkT8qIRJNa1UoL7Yh/s1600-h/viz_tour.png"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5309409656275993522" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjByU6klWufGCsf06dKu5pB6ExTBN6Lsu6Q-TJ9bGfx_qE_tJ-1jYLtg5qrGf1OrHej4Lq33NfJAP0Ep-8HuwwJQSlPy8SgCCbCxAkFPsMoOVcBZzEPPSmod3JSXBKBkT8qIRJNa1UoL7Yh/s400/viz_tour.png" style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 178px;" /></a>There is still a lot more work to do on Google Health, and we're excited to <a href="http://www.google.com/support/health/bin/request.py?contact_type=suggest">keep hearing from you</a> so we can continue to make improvements. For now, we hope this <a href="http://www.google.com/intl/en/health/whatsnew.html">new sharing feature</a> makes coordinating your care, or the care of loved ones, a little easier. Update on 3/6: Clarified the first bullet point. Posted by Sameer Samat, Director, Product Management</div>

Google Health: helping you better coordinate your care

We continue to learn a tremendous amount since launching Google Health in the spring of 2008. We're listening to feedback from users ev...

Đọc thêm »

IT Vulnerabilities Highlighted by Errors, Malfunctions at Veterans Medical Centers

Bill Gates's company, Microsoft, touts the <a href="http://www.interaction-design.org/encyclopedia/user_experience_or_ux.html">User Experience</a> as the Sine Qua Non of computing. Billions of dollars have been spent tweaking every little nuance of Windows, with version 7.0 soon to appear. Apple has done likewise with Mac OS X. (The various X-windows managers for Linux, less so). I respect these efforts and use both mainstream OS's in my daily work. In HIT, however, the "user experience" as I outlined in my eight part series <a href="http://tinyurl.com/hostileuserexper">starting here</a> is deemed an issue to solve once the sale is made and physicians are scrambling to avoid harming or killing patients. After all, the HIT industry is unregulated, shielded from liability based on the "learned intermediary" doctrine (a.k.a., clinicians are the bank and insurance company for IT vendors, in that they are the creative implementors of workarounds to IT mismanagement and misdesign), and contractual gag clauses against public disclosure of product defects. This arrangement makes the pharmaceutical industry look like kids in a sandbox. In the article "<a href="http://jama.ama-assn.org/cgi/content/extract/301/9/919">IT Vulnerabilities Highlighted by Errors, Malfunctions at Veterans' Medical Centers</a>", Journal of the American Medical Association 2009;301(9):919-920, author Bridget M. Kuehn illustrates the risk of improperly implemented or managed HIT, even in the VA. The VA is probably the finest environment in the world for HIT, its development of clinical IT over the past few decades being largely driven by experts from within, and being dedicated to patients and not profits. Yet its HIT is subject to the same issues as HIT in the for-profit HIT sector. Kuehn writes in JAMA: <blockquote style="font-family:arial;">Medical errors and software malfunctions that were linked to changes in the electronic medical records system used at Veterans Affairs (VA) medical centers across the country are drawing attention to the potential vulnerabilities of such systems. Although many advocates of electronic medical records systems promote them as a means to reduce mistakes affecting patient care, the recent problems in the VA system and other evidence suggest that malfunctions of these systems or problems with the way they are implemented have the potential to lead to medical errors. </blockquote> Drawing attention after how many years of physicians observing such problems in the commercial HIT sector and being muted by HIT companies on such issues, I ask? How many times will we need to see such articles in print before physicians and patient advocates wake up? How many times would we need to see in print "chiropractors performing neurosurgery is harming patients" before we put a stop to that practice? How many medical centers have lists and databases of known HIT defects, waiting to be fixed, that their patients and the public do not know of? How many physicians have been threatened with litigation for airing the dirty laundry? <blockquote>Understanding how such problems occur as well as how they might be prevented is particularly critical as the Obama administration considers health care reforms that include more widespread adoption of electronic records systems in health care. </blockquote> Indeed, although I would add "... as the Obama administration also moves from a suggested timeline of 2014 to a coercive 'do this or else' timeline." As I've written, such a change is cavalier and suffers from the misinformation fed the administration by both the <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/failurecases/?loc=cases&sloc=ecosystem">HIT ecosystem industrialists and opportunists</a>, and those suffering from the utopian Syndrome of Inappropriate Overconfidence in Computing. <blockquote style="font-family: arial;" face="arial">After a software update of the electronic medical records system at VA hospitals in August, health care workers at these facilities began to report that as they moved from the records of one patient to those of a second patient, they would sometimes see the first patient's information displayed under the second patient's name. </blockquote> If not for the diligence of the users, that type of error could lead to dead patients. <blockquote> This records-scrambling problem was reported at 41 of the 153 VA medical centers, said Gail Graham, deputy chief officer of Health Information Management at Veterans Health Administration Headquarters in Washington, DC. Graham explained that the jumbling of records was an uncommon occurrence that only occurred after a particular sequence of events. </blockquote> As I mentioned above, the VA is an example of the finest environment, probably in the world, for HIT, being dedicated to patients and not profits (see the book "<a href="http://books.google.com/books?id=JivKd9gTA5cC&pg=PT55&lpg=PT55&dq=%22scot+silverstein%22+medical+informatics+20+20%22&source=bl&ots=mAH8ZWDvYo&sig=RV5RI6AKTLZNoTfpmjq2TkrWAUE">Medical Informatics 20/20</a>" by Goldstein et al., and my linked quote, on that culture). Imagine what goes on in commercial products where vendors' first priority is to profit margin. <blockquote style="font-family:arial;">Health care workers at the VA medical centers were notified about this potential problem in October, and on December 20, the centers received a software "patch" to fix the problem. Nine VA medical centers reported another type of problem related to their electronic records system: physician orders to stop medication were missed, causing some patients to receive intravenous medications longer than necessary. The problem occurred because after the software upgrade, physician orders to discontinue such medications, which had previously appeared at the top of the screen, were not displayed. In 3 cases, patients received infusions of drugs such as heparin for up to 11 hours after their physician had ordered the drug to be discontinued. Graham said the affected patients were not notified because they had not been harmed by the oversights. This software problem was corrected on December 8. </blockquote> Again, this type of error occurs once too often, your patient's dead. <blockquote style="font-family:arial;">There are hundreds of types of problems that can occur as a result of such technology, and those experienced by the VA medical centers are not uncommon, according to Ross Koppel, PhD, professor of sociology at the School of Medicine at the University of Pennsylvania in Philadelphia. For example, the scrambling of two different electronic records is a common problem that is not limited to systems used in health care settings, he said. Additionally, research indicates that poor layout of information in electronic medical records and related health information technology systems is the most common type of flaw (Koppel R et al. JAMA. 2005;293[10]:1197-1203). He explained that when health care workers have to look at several different screens or scroll through pages to access the information needed to make medical decisions, mistakes can occur. </blockquote>My <a href="http://tinyurl.com/hostileuserexper">eight</a><a href="http://tinyurl.com/hostileuserexper"> part series</a> came to the same conclusions. In fact, I reached those conclusions and started <a href="http://www.ischool.drexel.edu/facuty/ssilverstein/medinfo.htm">writing publicly about them</a>, in 1998. Was anyone listening? How many patients have been harmed, or died, in those past ten years due to industry inattention to these issues and leadership of HIT projects by unqualified personnel? <blockquote style="font-family: arial;" face="arial">Additionally, medical errors also may arise from poor communication between electronic medical records and related technologies (such as computerized physician order entry systems) or between software applications created by different companies. Other types of errors are caused not by flawed software but by how workers use that software in real medical settings. For example, an electronic medical record system may require a physician to enter a weight for a patient before prescribing a drug, even if a precise weight is not needed for that particular drug. A physician in a rush may enter an estimate of the patient's weight, but another physician who subsequently views the record might use that estimated weight to prescribe a medication that does require an accurate weight, potentially causing a dosage error. Detecting such problems requires careful observation of how systems are being used in real clinical settings and interviewing clinical staff about their experience, noted Koppel.</blockquote> I claim these types of errors are due to flawed software. The flaw is in the ill-conceived, management information systems (MIS) inventory-system-mentality, mission hostile user experience the software presents to clinicians. <blockquote style="font-family:arial;">Although makers of electronic medical records software test it to detect problems that may lead to errors, federal oversight of such testing is lacking. The Certification Commission for Healthcare Information Technology, which is composed of health information technology industry organizations, has a certification program, but critics argue that such oversight is not sufficient and that the US Food and Drug Administration, the Centers for Medicare & Medicaid Services, or a new governmental agency should be given the authority to oversee these systems (<a href="http://www.ischool.drexel.edu/faculty/ssilverstein/regulation_and_oversight_hoffman.pdf">Hoffman S and Podgurski A. Harv J Law Tech. 2008;22[1]:104-165</a>). "The bar on certification has to be raised to a level that ensures real safety, not just minimal compliance," Koppel said.</blockquote> The CCHIT process is merely a specifications check or qualification of features, and is nearly useless by their own admission regarding most of the issues discussed in these articles. Worse, CCHIT has significant conflicts of interest with the HIT industry, having <a href="http://www.cchit.org/about/organization/commission/index.asp">senior people</a> who also hold senior industry positions and thus have fiduciary responsibilities to their employers (whether that is acceptable for a "certifying" organizations is open to debate, but the conflicts exist as fact). On a more minor point, this organization c<a href="http://hcrenewal.blogspot.com/2009/02/cchit-dissolved-involuntarily-in-april.html">an't even manage its books properly</a>, failing to file its required reports and temporarily being dissolved, involuntarily. In fact, let me state that the lack of oversight of this industry amounts to, at best, governmental negligence, and at worst a complete dereliction of obligation to protect the public. Imagine this type of arrangement in pharma or the (physical) medical device industry. Almost ten years ago I wrote HIT is a clinical tool for unforgiving medical environments that happens to involve computers, not a management information system that happens to involve doctors. In other words, HIT systems are virtual medical devices that affect every aspect of care, and can cause the "learned intermediaries" to commit error as the JAMA article illustrates. <blockquote style="font-family:arial;">Koppel also urged caution as electronic records are rolled out. Although these technologies offer great promise in providing data for research and quality-improvement initiatives, he said more work is needed to make these systems work effectively in the context of health care. "We should encourage [the technologies' development, but we should not force doctors to use them until they are shown to be more responsive to the needs of physicians and other clinicians," he said.</blockquote> As to the "they", I believe Ross Koppel was referring to the computer artifacts themselves. I would extend the "they" to mean the healthcare IT vendor industry itself, to most of whose leaders I've probably give an "F" regarding these issues and knowledge of Biomedical Informatics. Excluding <a href="http://www.nextgen.com/">NextGen</a>, whose AVP for Government Relations holds the vaunted and much coveted "<a href="http://hcrenewal.blogspot.com/2009/02/nextgen-and-vendordoctor-dialog-yet.html">American Medical Informatics Certification for Health Information Technology</a>." Finally, the VA is going to embark on <a href="http://linuxmednews.com/1194419534">upgrades to its laboratory components</a> not by relying on its internal expertise, but by engaging the services of a private HIT company, <a href="http://www.cerner.com/public/">Cerner</a>, a company with a troubled record regarding the national IT initiatives in the UK (see <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/failurecases/?loc=cases&sloc=granger_speaks_out">here</a>, <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/failurecases/?loc=cases&sloc=UK">here</a>). Considering that company's issues, and the internal complexities, dependencies, intra-component messaging, and other idiosyncracies of a system as complex as VistA, I opine that this is a major error. Based upon my <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/medinformatic1/gw-pdp8s.htm">decades of knowledge about IT</a>, biomedical informatics training, my analytical abilities and my own informed judgment, it is my deep fear that the VA will not "luck out" as in the above JAMA article. Patients will be harmed as a result somewhere down the line, I fear. -- SS Addendum 3/5/08: I am promoting a user comment and my response to the body of this post itself, as I think they exemplify a central issue regarding HIT: Paul Trossel on March 5, 2009 5:05:00 AM EST said... <blockquote style="font-family: arial;">Computer software in the Health industry are tools to use. Often the user thinks they are the ‘law’ in what they have to do. As long as people don’t understand the way they have to use their tools (eg surgical scalpel, machines, software etc.) mistakes will be made. Always check the outcome of the computer with your own judgement. As long as supervisors, bosses etc. help their people to understand that the use of the mind of a qualified professional is the outmost important and that the outcomes of the tools are the next, mistakes that lead to the death of a patient, will keep occurring!</blockquote> My reply: <blockquote style="font-family: arial;">Mr. Trossel, Forgive me for saying so, but you sound like an apologist for the Health IT medical device industry, which rightly fears increased scrutiny of its design, development, QC and lifecycle practices. HIT is a medical device that happens to involve computer automation. My apologies if I am incorrect, but it appears you're not taken care of a patient in the "fog of war" known as the ED, ICU or busy hospital floor. Tools that distract, tools that mislead, tools causing cognitive overload are simply dangerous in such an environment. That is a clinical reality. It is also clear you've not read my post [as above] in its entirety, nor my <a href="http://tinyurl.com/hostileuserexper">multi part series on the mission hostile user experience</a> presented by HIT. It appears even the most highly trained experts, especially when distracted, can be misled by faulty devices. The recent crash of the Turkish airliner seems a case of just that. See "<a href="http://blogs.wsj.com/middleseat/2009/03/05/turkish-airlines-amsterdam-crash-altimeter-crew-cited-as-causes/" rel="nofollow">Altimeter, Crew Cited in Dutch Crash</a>" in the Wall Street Journal. It is the primary responsibility of the manufacturer of a medical device such as HIT to assure it is the best device possible, accounting for the very well known realities of the clinical workplace. It is not the responsibility of the end user to be the bank and insurance policy for cavalier software design through tiring improvisation and workarounds to software device mismanagement and design decisions made by incompetents and HIT amateurs. </blockquote> There is no excuse for ill conceived, designed and implemented HIT devices. None whatsoever, most especially depending on busy human users to compensate for the flaws on a 100% reliability basis. <a href="http://www.resilience-engineering.org/">Resilience engineering</a>, a term I learned when presenting these HIT issues to the <a href="http://www.ieeeusa.org/volunteers/committees/mtpc/">IEEE Medical Technology Policy Committee</a> in Dec, 2007 (PPT <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/IEEE_12102007.zip">here</a>), is not about depending on busy people to cover for your device's defects. Regarding a meta-issue: It's absolutely a sign of our culture being in great distress when physicians have to answer to IT personnel about why the physicians best not be the "workarounds" and safety valves to ill conceived IT. -- SS

IT Vulnerabilities Highlighted by Errors, Malfunctions at Veterans Medical Centers

Bill Gates's company, Microsoft, touts the User Experience as the Sine Qua Non of computing. Billions of dollars have been spent tweak...

Đọc thêm »

Outrageous extremely overpriced ridiculously simple EMR interfaces

This in from a 2005 college graduate working in healthcare IT for almost 3 years, with a technical background only, who has found my <a href="http://www.ischool.drexel.edu/faculty/ssilverstein/medinfo.htm">site on HIT difficulties</a>. This person's been working with several hospitals and hospital groups to create interfaces to practices and labs as well as master patient index services. This HIT worker writes: <blockquote style="font-family:arial;">"...one other thing that I think should be covered is the outrageous extremely overpriced ridiculously simple (I opted to use as many adjectives that came to mind) task of creating an interface in an EMR. After doing a few interfaces myself and working with about a dozen or so EMR vendors the cost is ridiculous for the amount of work they actually do. The average cost that I've seen is about $4,000 to $6,000 USD, I've seen some that are 'free' I'll explain this one later, some upwards of $40,000+ and some in the realm of a few hundred. Under this secret shroud of "everything is complicated and takes tons of people and costs an arm and a leg" is really a two person job that takes about three to four hours, or even less if you know what you're doing. To create an interface between two systems one person configures their application to listen on a socket, and the other to configure the application to connect to an IP and a specific socket. This of course assumes the two systems are maintained by two different people. There is more that goes into creating an interface sure, but from an EMR point of view its two people. I've configured a [Big Vendor] interface with the vendor in 30 minutes. [Big Vendor] charges I think the number was $3,500 to $4,000 for the "Labor charge", [Big Vendor] is the 'free' one once you purchase the application you can create as many interfaces as you want. I've yet to meet a physician, nurse or office assistant that have the know-how to create an interface. Other EMR's charge per interface as if paying $15,000 for the application wasn't enough a physician must spend another $4,000 to $6,000 for a stinking interface! Yes its important that they have it but WOW! - $4,000 to $6,000 for 30 minutes of work? Some are longer, some interfaces require more configuration's which isn't much, most any worthwhile application already has default configurations and interfaces so one could load those and not go too far over 30 minutes of work, certainly not longer than a few hours though. Thinking of a typical practice that I've encountered, there are three general feeds: 1. General Labs - This interface would send over your microbiologies,blood tests etc. 2. Transcriptions - This interface would send over, well, transcriptions anything dictated. 3. Radiology - This interface would send over all your radiology transcriptions with the added feature of being able to handle images. Not that I've actually seen one in action, these are all just claims right now. The sheer size of radiology images dissuades labs from sending them over the system because of bandwidth issues, also because not many interfaces currently support DICOM, or one system in the flow doesn't support DICOM. So, if we take one of the larger EMR's, your eCW's, GE's, Misys's, Allscripts et cetera, the cost for one of these systems range from $12,000 to $15,000 that I've seen for a small practice. Then if you take the $4000 (lets be nice and give EMR's the lower number) at three interfaces for a total of $12,000 we have a system that costs $24,000 to $27,000. That's ridiculously insane for a broken system that somewhat works. Another thing that has always got me wound up with looking at these costs are that the EMR's know their application best, they know how the HL7 data should look, but they have no way of mapping the HL7 to be compliant with their systems. So I'm forced to map it for them, I'm lucky if they have specs, and if they do they're likely out dated (I have yet to receive a spec that was not out of date by the way). Reverse engineering an application's interpretation of HL7 is insane. To be fair, some vendors do offer though to do the mapping, then again they also charged $40,000+. I've tinkered with EMR systems when I can, some were nice, some were trash, most were trash. These applications work and look great for me, but lets face it, I'm no clinician I don't understand most of what is on the screen, I can fumble around though and figure things out. These applications are designed and developed by engineers, these applicationsonly make sense to engineers. These systems are pure trash. Here's to taking down the shroud and smoke screen HIT has put up the past couple decades. Feel free to post this in its entirety if it will help take down the smoke screen. </blockquote> Having been a CMIO, I can vouch for these expense levels charged for interfaces that I knew, also being a computer professional, were quite simple to code. -- SS

Outrageous extremely overpriced ridiculously simple EMR interfaces

This in from a 2005 college graduate working in healthcare IT for almost 3 years, with a technical background only, who has found my site on...

Đọc thêm »

The Malpractices of the Multitudes: the HIT Mission Hostile User Experience, Part 8

More on the origin of this post's title, penned in 1836, below. (Note: Part 1 of this series is <a href="http://hcrenewal.blogspot.com/2009/02/are-health-it-designers-idiots-part-1.html">here</a>, part 2 is <a href="http://hcrenewal.blogspot.com/2009/02/are-health-it-designers-testers-and.html">here</a>, part 3 is <a href="http://hcrenewal.blogspot.com/2009/02/are-health-it-designers-testers-and_24.html">here</a>, part 4 is <a href="http://hcrenewal.blogspot.com/2009/02/are-health-it-designers-testers-and_26.html">here</a>, part 5 is <a href="http://hcrenewal.blogspot.com/2009/02/are-health-it-designers-testers-and_27.html">here</a>, part 6 is <a href="http://hcrenewal.blogspot.com/2009/02/it-makes-healthcare-easier-is-this.html">here</a>, part 7 is <a href="http://hcrenewal.blogspot.com/2009/03/information-technology-makes-healthcare.html">here</a>, and part 8 is <a href="http://hcrenewal.blogspot.com/2009/03/malpractices-of-multitudes-mission.html">here</a>. 2011 addendums: a post that can be considered part 9 is <a href="http://hcrenewal.blogspot.com/2011/04/special-k-red-berries-mission-hostile.html">here</a>, part 10 is <a href="http://hcrenewal.blogspot.com/2011/12/ehr-mission-hostile-user-experience.html">here</a>.) This post is part 8 of a series on the stunningly poor human engineering of production healthcare IT from major vendors, in use today at major medical centers. These devices provide a decidedly mission hostile user experience, yet with an almost religious fervor are being touted as cybernetic miracles to cure healthcare's ills. <blockquote>April 2011 addendum: see what might be considered part 9 <a href="http://hcrenewal.blogspot.com/2011/04/special-k-red-berries-mission-hostile.html">at this link</a>.</blockquote> My college is a member of the <a href="http://www.ischools.org/">iSchool</a> consortium, consisting of schools of information science and technology (notably, not "information technology and science"). <blockquote>The iSchools are interested in the relationship between information, people and technology. This is characterized by a commitment to learning and understanding the role of information in human endeavors. The iSchools take it as given that expertise in all forms of information is required for progress in science, business, education, and culture. This expertise must include understanding of the uses and users of information, as well as information technologies and their applications.</blockquote> Note the "as well as." Note the primary focus, and that which is secondary. This philosophy parallels that of Medical Informatics well. This probably sounds like Martian to many in the healthcare and perhaps the broader business IT sector. One of my colleagues on reviewing this HIT series had this to say: <blockquote style="font-family: arial;"> It's really nice to hear that for once IT professionals have been able to successfully repeat the development lifecycle for healthcare information systems: <ul><li>Fail to understand the problem -></li></ul><ul><li>create a fragmentary and inaccurate requirements definition -></li></ul><ul><li>design an ambiguous, ignorant and risk-laden user interface -></li></ul><ul><li>pull all the misguided notions together with baling wire and call it a design-></li></ul><ul><li>translate the "design" into an executable form, adding and subtracting design elements at random -></li></ul><ul><li>observe the first output from the system and declare it ready for the healthcare professionals. fini</li></ul> Did I miss anything?</blockquote> I believe he captured the essense of today's HIT vendor market well. Here are examples of screen displays of vital patient information, displays that force clinicians to go on wild goose chases and seem designed by true neophytes to the field of information presentation and user interaction design. This is not to single out any one vendor. Many vendor products have deficiencies. See this display of something as simple (one would think) as blood pressures: <div style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmvltC6XKg9_afHVtZV2WZ0TvHAEIQpEvXBBWRHkdj_uuUXFofKZ2vd0m7pZL6Y4fvgSG6IAvDZi-01x6FXwiJkE_qXeJklZRtWJlnhM31qXTn9IAN3SoBIXy4f96AVCypr5rGSyeAt_N9/s1600-h/bp1.jpg" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5309109363406374482" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmvltC6XKg9_afHVtZV2WZ0TvHAEIQpEvXBBWRHkdj_uuUXFofKZ2vd0m7pZL6Y4fvgSG6IAvDZi-01x6FXwiJkE_qXeJklZRtWJlnhM31qXTn9IAN3SoBIXy4f96AVCypr5rGSyeAt_N9/s320/bp1.jpg" style="cursor: pointer; display: block; height: 269px; margin: 0px auto 10px; text-align: center; width: 429px;" /></a>(click to enlarge) <div style="text-align: left;"> Note the following: <ul><li>Diastolic blood pressures in the left column;</li><li>Systolic blood pressures in the roight column;</li><li>An adventure to match them by date;</li><li>No column headers at top.</li></ul> Which value goes with which? How much energy does it use up to scroll around and connect the two? This display is so poorly conceived, one wonders why it was included at all in a production system. There's more. Let's troll for data, shall we? See the blood oxygen saturation level, circled? <div style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiu905SrE7UWqih06dfekAG55ypw5xED6AUaRoRY0-Wjr3odjrpQwAA0mFgxu_zx5a8LbhNks40uBeNXXNv2_yvqiAWSrOj2hUKa0wQfBvya9VrIq6Me0IhzX8dvcpx_eos6H6JZaND5VxJ/s1600-h/pulseox1.jpg" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5309111713343813090" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiu905SrE7UWqih06dfekAG55ypw5xED6AUaRoRY0-Wjr3odjrpQwAA0mFgxu_zx5a8LbhNks40uBeNXXNv2_yvqiAWSrOj2hUKa0wQfBvya9VrIq6Me0IhzX8dvcpx_eos6H6JZaND5VxJ/s320/pulseox1.jpg" style="cursor: pointer; display: block; height: 317px; margin: 0px auto 10px; text-align: center; width: 433px;" /></a>(click to enlarge)</div> What percentage oxygen was this patient receiving? It's not there! Where is it? Scroll down ... <div style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh3mRxHdhg82E8YHmARGw4DK8MJSWJAmfPNBNaoZgRgTjdTu5E39LXvMM9uzmnJcBMEIzZAcEHf_OSMzFghi2teoOZoTIIRKiWgkSMon2E6SjcYik8-YLh70lTnjAAL6RTh5Yoyw1aI5E6M/s1600-h/pulseox2.jpg" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5309112826374552962" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh3mRxHdhg82E8YHmARGw4DK8MJSWJAmfPNBNaoZgRgTjdTu5E39LXvMM9uzmnJcBMEIzZAcEHf_OSMzFghi2teoOZoTIIRKiWgkSMon2E6SjcYik8-YLh70lTnjAAL6RTh5Yoyw1aI5E6M/s320/pulseox2.jpg" style="cursor: pointer; display: block; height: 342px; margin: 0px auto 10px; text-align: center; width: 412px;" /></a>(click to enlarge)</div> ... and down ... <div style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifM6KQKapHXEeScoAmiSvodQhpSkZ5RwkVCT_sWpAGAeD9yi47aTcHPd-ZyA69UxpnnG-8cZx0d-7Pe5iKgUBtkV0rqsckNYHiOZNhyphenhyphenEwiVTVxezg5MLgUJCSD1DiMSgelxAPUVUER64wD/s1600-h/pulseox3.jpg" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5309114210505780354" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifM6KQKapHXEeScoAmiSvodQhpSkZ5RwkVCT_sWpAGAeD9yi47aTcHPd-ZyA69UxpnnG-8cZx0d-7Pe5iKgUBtkV0rqsckNYHiOZNhyphenhyphenEwiVTVxezg5MLgUJCSD1DiMSgelxAPUVUER64wD/s320/pulseox3.jpg" style="cursor: pointer; display: block; height: 336px; margin: 0px auto 10px; text-align: center; width: 403px;" /></a>(click to enlarge) <div style="text-align: left;"> Our answer, at last! Circled. Of course, the corresponding pulse oximetry is now off the screen. How much attention would it have taken to present the two together? How much coding would it have taken with today's computers, that execute billions of instructions per second, to dynamically condense the presentation of information, eliminating the absolutely empty cells between the two values? Similar isses are noted for other biomedically coupled values, such as coumadin dose and blood thinning value (INR). Screw matching those up, and as my mentor Victor P. Satinsky, MD might have said, your patient's dead. Speaking about information sparsity, how's this display? <div style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2u2XuKF_6ev1jaMi8nrl9NHK2pZueIvVWxEmRvdR9YewzNfU43HZ3A9hvThFc08qRN9cwz1moU_AVZVg3f52lM9m2SWdIZxbdfDrPLopxlzU10V7AF_u1QD4LpqbT3aiLRk0A3vX16Piv/s1600-h/sparse.jpg" onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5309115566446043474" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2u2XuKF_6ev1jaMi8nrl9NHK2pZueIvVWxEmRvdR9YewzNfU43HZ3A9hvThFc08qRN9cwz1moU_AVZVg3f52lM9m2SWdIZxbdfDrPLopxlzU10V7AF_u1QD4LpqbT3aiLRk0A3vX16Piv/s320/sparse.jpg" style="cursor: pointer; display: block; height: 311px; margin: 0px auto 10px; text-align: center; width: 428px;" /></a>(click to enlarge) <div style="text-align: left;">There's one value in the entire screen. What a waste. How much difficulty would it have been to simply present the one row, automatically? The EHR disperses and fragments vital patient information. How, exactly, is this is supposed to make clinicians more efficient and less error prone? I am only presenting the easiest to present problems, easiest that is in a static medium such as a blog. If presented dynamically, we find with some EHR's, for example, that it takes 50 or so mouse clicks across various screens and drop down lists and drop boxes to enter 5 common diagnoses. It takes selecting from multiple hierarchical lists and buttons across four different screens, multiple times repetitively, to find out how well a patient is eating. Here is simple advice from J Gen Intern Med 2009; 24(1):21-26. <blockquote> It is imperative that usability principles are embedded in CPOE design to avoid • overly complex screens • poor grouping of like terms • an inflexible human-computer interface • mis-use of clinician time</blockquote> Do the HIT vendors actually read such advice? I wonder. Medical Informatics reminds me of dentistry in its early days. B.T. Longbothom, author of the second dentistry book published in the U.S. ("A Treatise on Dentistry", 1802), gave an excellent description in his preface of problems at the time. His observations apply to Medical Informatics in our present age: <blockquote face="arial">The word "dentist" has been so infamously abused by ignorant pretenders, and is in general so indifferently understood, that I cannot forbear giving what I conceive to be its original meaning: viz, the profession of one who undertakes and is capable not only of cleaning, extracting, replacing by transplantation and making artificial teeth, but can also from his knowledge of dentistry, preserve those that remain in good condition, prevent in a very great degree, those that are loose, or those that are in a decayed state, from being further injured, and can guard against the several diseases, to which the teeth, gums and mouth are liable, a knowledge none but those regularly instructed, and who have had a long, and extensive practice, can possibly attain, but which is absolutely necessary, to complete the character of a Surgeon Dentist.</blockquote> Hardly anyone spoke out. More than thirty years later, untrained practitioners were as prevalent as ever. One of the leading dentists of the time, Shearjashub Spooner, in his "Guide to Sound Teeth, or, A Popular Treatise on the Teeth" (1836) warned the public of a phenomenon I believe now applies to Medical Informatics and healthcare IT: <blockquote style="font-family: arial;"> One thing is certain, this profession must either rise or sink. If means are not taken to suppress and discountenance the malpractices of the multitude of incompetent persons, who are pressing into it, merely for the sake of its emoluments, it must sink, - for the few competent and well educated men, who are now upholding it, will abandon a disreputable profession, in a country of enterprise like ours, and turn their attention to some other calling more congenial to the feelings of honorable and enlightened men.</blockquote> I understand that point of view. And with that, I end this series. -- SS </div></div></div></div></div></div>

The Malpractices of the Multitudes: the HIT Mission Hostile User Experience, Part 8

More on the origin of this post's title, penned in 1836, below. ( Note: Part 1 of this series is here , part 2 is here , part 3 is h...

Đọc thêm »