Perhaps doctors should be more like the President.
After all, we also carry the ultimate responsibility for our constituents, even though we, too, have team members who do part of that work.
The way I understand things to work at the White House, those other team members collect, review and prioritize the information the President needs in order to manage his, and all our, business.
That is how things used to work in medicine, too, before computerization revolutionized our workflows: Nurses, medical assistants or secretaries would open the mail, gather the faxes, look over the lab and X-ray reports and put them on physicians’ desks in a certain order. Highly abnormal or time-sensitive information would be prioritized over routine “signature-needed” forms, and in my case, essentially normal reports on patients already scheduled to be seen within a few days wouldn’t even reach my eyes until the patient appointment.
Computers changed all that.
Now, most of the information goes straight to the doctors’ inboxes, unseen by other human eyes in the office. This is said to be faster. It is, to a degree, in the sense that the information leaves the laboratory or the X-ray department faster via their Internet connected computers. But in the typical medical office, we have now turned decision making doctors into frontline mail sorters and de facto bottlenecks of routine information.
A rash could be leukemia or idiopathic thrombocytopenic purpura. A sore throat could be glossopharyngeal neuralgia or a retropharyngeal abscess. A blocked ear could be Ramsay-Hunt syndrome, a self-limited serous otitis or sudden sensorineural hearing loss with an abysmal prognosis if not treated immediately with high doses of steroids. A headache or sinus pain could be cancer, and a cough could be a pulmonary embolus or heart failure.
Treating the Well:
In my early career in Sweden, well child visits were done in nurse-led clinics, some of them only open on certain days, with a local doctor in attendance. Parents carried the children’s records with them, containing growth charts, immunization records and so on.
These nurses had great expertise in differentiating normal from abnormal appearance of children, and would direct the attending physician’s attention to children with abnormal metrics, appearance or behavior.
With this arrangement, the physician time requirement was reduced, and limited to evaluating children attending the clinics who needed special attention. Physicians also performed specific examinations at certain ages, such as checking for hip clicks. These clinics freed up the local pediatricians to evaluate more sick children.
Well-baby visits are now the bread and butter of American pediatricians and family practitioners, and with the ever expanding mandates of politically determined items that must be covered in order for doctors to get paid for their services, we sometimes have trouble accommodating illness care demands.
When building software, requirements are everything.
And although good requirements do not necessarily lead to good software, poor requirements never do. So how does this apply to electronic health records? Electronic health records are defined primarily as repositories or archives of patient data. However, in the era of meaningful use, patient-centered medical homes, and accountable care organizations, patient data repositories are not sufficient to meet the complex care support needs of clinical professionals. The requirements that gave birth to modern EHR systems are for building electronic patient data stores, not complex clinical care support systems–we are using the wrong requirements.
Two years ago, as I was progressing in my exploration of workflow management, it became clear that current EHR system designs are data-centric and not care or process-centric. I bemoaned this fact in the post From Data to Data + Processes: A Different Way of Thinking about EHR Software Design. Here is an excerpt.
Do perceptions of what constitutes an electronic health record affect software design? Until recently, I hadn’t given much thought to this question. However, as I have spent more time considering implementation issues and their relationship to software architecture and design, I have come to see this as an important, even fundamental, question.
The Computer-based Patient Record: An Essential Technology for Health Care, the landmark report published in 1991 (revised 1998) by the Institute of Medicine, offers this definition of the patient record:
A patient record is the repository of information about a single patient. This information is generated by health care professionals as a direct result of interaction with the patient or with individuals who have personal knowledge of the patient (or with both).
Note specifically that the record is defined as a repository (i.e., a collection of data). There is no mention of the medium of storage (paper or otherwise), only what is stored. The definition of patient health record taken from the ASTM E1384-99 document, Standard Guide for Content and Structure of the Electronic Health Record, offers a similar view—affirming the patient record as a collection of data. Finally, let’s look at the definition of EHR as it appears in the 2009 ARRA bill that contains the HITECH Act:
ELECTRONIC HEALTH RECORD —The term ‘‘electronic health record’’ means an electronic record of health-related information on an individual that is created, gathered, managed, and consulted by authorized health care clinicians and staff. (123 STAT. 259)
Even here, 10 years later, the record/archive/repository idea persists. Now, back to the issue at hand: How has the conceptualization of the electronic health record as primarily a collection of data affected the design of software systems that are intended to access, manage, and otherwise manipulate said data?
With the announcement that the FDA granted 510(k) approval for the AliveCor EKG case for the iPhone 4/4s, the device became available to “licensed U.S. medical professionals and prescribed patients to record, display, store, and transfer single-channel electrocardiogram (ECG) rhythms.”
While this sounds nice, how, exactly, does one become a “prescribed patient?” Once a doctor “prescribes” such a device, what are his responsibilities? Does this obligate the physician to 24/7/365 availability for EKG interpretations? How are HIPAA-compliant tracings sent between doctor and patient? How are the tracings and medical care documented in the (electronic) medical record? What are the legal risks to the doctor if the patient transmits OTHER patient’s EKG’s to OTHER people, non-securely?
At this point, no one knows. We are entering into new, uncharted medicolegal territory.
But the legal risks for prescribing a device to a patient are, sadly, probably real, especially since the FDA has now officially sanctioned this little iPhone case as a real, “live” medical device. But I must say, I am not a legal expert in this area and would defer to others with more legal expertise to comment on these thorny issues.
This issue came up because a patient saw the device demonstrated in my office and wanted me to prescribe it for them. So I sent AliveCor’s Dr. Dave Alpert a tweet and later received this “how to” e-mail response from their support team:
Somewhere between the 20th century Bank ATM and the 25th century Tricorder, lays the EMR that we should have today.
Somewhere between the government-designed Meaningful Use EMR and the Holographic doctor in Star Trek, there should be a long stretch of disposable trial-and-error cycles of technology, changing and morphing from good to better to magical. For this to happen, we must release the EMR from its balls and chains. We must release the EMR from its life sentence in the salt mines of reimbursement, and understand that EMRs cannot, and will not, and should not, be held responsible for fixing the financial and physical health of the entire nation. In other words, lighten up folks …
A patient’s medical record contains all sorts of things, most of which diminish in importance as time goes by. Roughly speaking, a medical record contains quantifiable data (numbers), Boolean data (positive/negative), images (sometimes), and lots of plain, and not so plain, English (in the US).
The proliferation of prose and medical abbreviations in the medical record has been attacked a very long time ago by the World Health Organization (WHO), which gave us the International Classification of Disease (fondly known as ICD), attaching a code to each disease. With roots in the 19th century and with explicit rationale of facilitating international statistical research and public health, the codification of disease introduced the concept that caring for an individual patient should also be viewed as a global learning experience for humanity at large. Medicine was always a personal service, but medicine was also a science, and as long as those growing the science were not far removed from those delivering the service, both could symbiotically coexist.
Everyone, including this blog writer, has been touting the virtues of the vast troves of data already or soon to be available in the electronic health record (EHR), which will usher in the learning healthcare system [1, 2]. There is sometimes unbridled enthusiasm that the data captured in clinical systems, perhaps combined with research data such as gene sequencing, will effortlessly provide us knowledge of what works in healthcare and how new treatments can be developed [3, 4]. The data is unstructured? No problem, just apply natural language processing .
I honestly share in this enthusiasm, but I also realize that it needs to be tempered, or at least given a dose of reality. In particular, we must remember that our great data analytics and algorithms will only get us so far. If we have poor underlying data, the analyses may end up misleading us. We must be careful for problems of data incompleteness and incorrectness.
There are all sorts of reasons for inadequate data in EHR systems. Probably the main one is that those who enter data, i.e., physicians and other clinicians, are usually doing so for reasons other than data analysis. I have often said that clinical documentation can be what stands between a busy clinician and going home for dinner, i.e., he or she has to finish charting before ending the work day.
I also know of many clinicians whose enthusiasm for entering correct and complete data is tempered by their view of the entry of it as a data blackhole. That is, they enter data in but never derive out its benefits. I like to think that most clinicians would relish the opportunity to look at aggregate views of their patients in their practices and/or be able to identify patients who are outliers in one measure or another. Yet a common complaint I hear from clinicians is that data capture priorities are more driven by the hospital or clinic trying to maximize their reimbursement than to aid clinicians in providing better patient care.
In my recent post Work Induced Attention Deficit Disorder, several commenters asked how I stay focused and productive, speculating that I leverage my limited need for sleep.
Although having a 20 hour day helps, the real secret is that I end each day with an empty inbox. I have no paper in my office. I do not keep files other than those that are required for compliance purposes.
The end result is that for every document I’m asked to read, every report I’m ask to write, and every situation I’m asked to management, I only handle the materials once.
What does this mean?
In a typical week, I’m asked to review 4 or 5 articles for journals. Rather than leaving them to be read at some later time or reading them then deferring the review, I read and review them the day they are assigned. This enables me to read them once and write the review very efficiently since all the facts are fresh in my mind.
Why are doctors so slow in implementing electronic health records (EHRs)?
The government has been trying to get doctors to use these systems for some time, but many physicians remain skeptical. In 2004, the Bush administration issued an executive order calling for a universal “interoperable health information” infrastructure and electronic health records for all Americans within 10 years.
And yet, in 2011, only a fraction of doctors use electronic patient records.
In an effort to change that, the Obama economic stimulus plan promised $27 billion in subsidies for health IT, including payments to doctors of $44,000 to $64,000 over five years if only they would use EHRs. The health IT industry has gathered at this multibillion-dollar trough, but it hasn’t had much more luck getting physicians to change their ways.
What is wrong with doctors that they cannot be persuaded to adopt these wondrous information systems? Everybody knows, after all, that the Internet and mobile apps, powered by Microsoft, Google, and Apple and spread by Facebook, Twitter, YouTube, and the iPhone and iPod, will improve care and cut costs by connecting everybody in real time and empowering health-care consumers.
Yesterday, Chilmark Research participated in the CRG conference, Driving Change Through Managed Care IT from Provider Payments to Quality, which was held in New York City. Despite having a title that no one will be able to remember, the overall theme of the event and presentations therein gave one a bird’s eye view into what payers are thinking as we march forward with healthcare reform and the digitization of the healthcare sector.
A common theme that repeated itself numerous times over the course of the day was the lack of business process maturity in the healthcare sector. Meg McCarthy, EVP of Innovation at Aetna was the first to make this statement citing this issue as arguably the number one challenge for this industry sector to overcome. (McCarthy provided some interesting details on the Medicity acquisition but we’ll save that for a later date.)
Later that day, Jessica Zabbo, Provider Technology Supervisor at RI-BCBS gave a very detailed presentation on her company’s experiences working with providers on the adoption and use of EHRs. Over the last several years RI-BCBS has done a couple of small pilots. In both cases a defining parameter of success was business process maturity. For example, the company did a Patient Centered Medical Home (PCMH) pilot that coupled pay for performance metrics (P4P) with EHR use. Basically P4P measurements were to be recorded and reported through the EHR. One of the key lessons learned was that P4P program success was highly dependent on the EHR being fully implemented and physicians comfortable with its use (process maturity). But in a Catch-22, to successfully incorporate P4P metrics into the EHR requires a very deep understanding of practice focus and workflow. Without that understanding, failure of the P4P program is almost certain.Continue reading…
It has become politically incorrect to refer to EHRs as products. Instead, EHRs are now “technologies” as evident in all ONC and CMS published rules and regulations. This subtle change in terminology was intended to encourage, yes you guessed it, Innovation. It was supposed to signal an open market for alternatives to existing EHR products in the form of modular approaches, open platforms, mobile applications and web-based software-as-a-service. Naturally, the industry is obliging and all efforts now are geared towards creating stuff that runs on iPads, preferably “cloud” based and with minimal utility. The new stuff looks very cool and promises to become even cooler, so what’s the problem?
The problem is that these new things do not solve any problems. Traditional product innovation concentrated on identifying problems, designing solutions and then selecting technologies that were capable of enabling those solutions. New technologies were usually born out of the necessity to solve a burning problem and those with enough applicability to larger markets became blockbusters. Every frying-pan today sports technology first invented in the process of creating refrigerants and later used for nuclear destruction (Teflon). Every large enterprise embarking on cost cutting, new markets acquisition, or general improvements, should know all too well that selecting a “cool” technology first, and then attempting to find a good use for it, is recipe for failure.