Dr. Bob HIT Thoughts Blog Index
Breach Notification-Part 1 Oct. 15, 2009
Breach Notification-Part 2 Oct. 26, 2009
Certification July 29, 2009
Certification Follow-up Aug. 19, 2009
Consumer Preferences Nov. 2, 2009
Dr. Blumenthal--An Inspirational Keynote Address
at HIMSS10 Mar. 7, 2010
EHR Safety Feb. 21, 2010
EMR Certification Revisited Nov. 17, 2009
EMR Usability Nov. 22, 2009
Future Role for HITSP? Dec. 2, 2009
Handheld Devices-the Mobile Clinician Jan. 9, 2010
Health Information Exchange Aug. 18, 2009
Health IT Workforce Training Dec. 27, 2009
HIT Workforce Training Dec. 14, 2009
IFR on Standards and NPRM on Meaningful Use Feb. 16, 2010
Introduction July 17, 2009
It's all about workflow Mar. 31, 2010
Meaningful Use and Incentives to adopt HIT July 21, 2009
Online Education Sept.10, 2009
Online Graduate Degrees-My Experience Nov. 18, 2009
Quality Reporting Sept. 30, 2009
Reconciliation-an unmet Challenge Sept. 14, 2009
Summary of the HIT Policy Committee
Workgroup hearing on EHR Safety Mar. 15, 2010
Thought on the NHIN Mar. 18, 2010
Wednesday, March 31, 2010
It's all about workflow
One of the words that I heard repeatedly at HIMSS10 this month was workflow. As I set out to write this post, I realized that I was not sure I really knew what workflow was. I visited the Wikipedia webpage concerning workflow. It had a lot of interesting information that helped me realize that I probably did not understand all the possible applications of workflow. I highly recommend this page to others. Interestingly, the shortest and most apropos definition described workflow, when used in the computing domain, as the interaction of human and machine. The tight association of workflow and quality topics was an unexpected enlightenment. I have tried to look at how workflow issues affect clinicians who use electronic health records in the paragraphs below. I will provide examples of how workflow is impacted.
Augmented productivity, improved safety or quality of medical care. 1) Order sets. Clinicians learn to write orders from day one in their clinical training. Ordering is a major process used to provide medical care. The use of order sets has many advantages over handwritten orders. First, teams of clinicians come together to design the order set and try to incorporate best practices from their own experiences and recent medical literature. For the clinician at the point of care, it is possible to "write" lengthy orders with just one or several clicks of the mouse. For recipients of orders, they are concise and legible, and standardized. For patients, order sets may assure that they are receiving the best care possible. 2) Electronic prescribing (eRx). A number of published studies have shown the efficacy of eRx in increasing the efficiency of care, minimizing medical errors caused by poor legibility of handwritten prescriptions, similarity of certain drug names, and incorrect dosing decisions. The ambulatory office workflows with eRx, especially for prescription renewals, can greatly increase clinician efficiency. As information exchanges grow, formulary checking and optimization present the potential of time and money savings for all. A thorny issue for the workflow of electronic prescribers has been the regulatory prohibition against the use of eRx for controlled substances. The FDA should be publishing an interim final rule (IFR) on this topic in the Federal Register today (preliminary document can be found here.) This long-awaited rule should help eliminate one of the major barriers to more wide-spread adoption of eRx. 3) Simple Decision Support. Alerts and reminders, when thoughtfully implemented, have been shown to improve the safety and quality of care, especially with respect to the medication ordering process. Already, innumerable errors have been prevented where drug-drug, drug-allergy, or drug-disease checking are performed automatically. These alerts fit perfectly into the clinical workflow because they appear while the drug ordering process is underway. I will discuss the more complex forms of clinical decision support below.
Examples where the workflow effects have primarily been detrimental in the clinical environment. 1) When the clinician moves quickly from one geographical point of service to another. Provider access to computer workstations and other hardware remains problematic. Clinicians continue to complain about the barriers created by security and privacy policies and procedures. Usernames and frequently changing passwords are a source of frustration. Use of single sign-on methods help but still are not a panacea. Furthermore, there is a trend toward true two factor authentication (see requirements in electronic prescribing of controlled substances rule above) in health care systems that may exacerbate the problem. Smart cards, proximity cards and biometric techniques may help mitigate clinician frustration. Somehow, I believe a technical solution to this conundrum will be developed in the future. 2) Infrequent tasks. It is human nature to forget how perform tasks that are done infrequently. It can be more difficult to create electronic orders for treatments that don't fit neatly into order sets. Good initial and recurrent training, superuser availability, and access to effective help assets-help desks, help menus, online-on-demand training, can all serve to limit clinician dissatisfaction.
Examples with variable, questionable or unknown effects. 1) Advanced Clinical Decision Support. This flavor of CDS usually addresses the more complex scenarios involved in acute and chronic disease management. CDS here is usually implemented through the use of structured order sets. The workflow challenge is to automatically deliver needed information to the clinician when and where needed (or at least make manual access to detailed information simple and imbedded in the same application.) Another difficulty is integration of CDS systems and EHRs. The correct data need to be collected and stored in the EHR to enable maximum CDS utility. Strategically placed info buttons allow clinicians to drill deeper for detailed information and to examine the original sources for evidence-based guidelines. Another challenge is the use of diagnostic decision support. When the diagnosis of a patient's condition is not known, then use of diagnostic CDS is an obvious course of action. Here the problem is making sure that enough of the correct data from history, physical, laboratory studies, radiology, and other studies is available to the CDS system so that it can provide a list of diagnoses that has a high probability of containing the one that is correct. Another problem for diagnostic CDS is that it cannot be helpful unless the clinician activates it. If a clinician decides to treat a patient based on an incorrect diagnosis, then the patient is not likely to get better. The difficulty for the clinician is knowing what you don't know. Here is a good example. A colleague of mine treated a patient with a large blister on the inner side of his foot with antibiotics and surgery. He thought it was an infection. Later, he asked me to consult because I had special training in foot and ankle surgery. I reviewed the patient's chart and I noted there was a history of regional enteritis and in fact the patient had a small fistula from the bowel to his abdominal wall. The photograph of the initial skin lesion looked like a bullous to me. There are relatively few conditions that manifest with bullous-like skin lesions. A quick check on the Internet yielded the correct diagnosis-pyoderma gangrenosum-a skin condition associated with inflammatory bowel disease that requires treatment with high dose steroids. This is a medication we would not use to treat infections. As a clinician there is always the fear-how do you know what you don't know? 2) Clinical Documentation. Many clinicians find documentation to be more difficult and slower with EHR technology than with traditional paper-based record keeping methods. Often, clinicians use keyboard entry of data but a large proportion finds this method to be slow, awkward, and intrusive. Template driven documentation can be efficient in some settings but is difficult to use for more nuanced requirements of treating a patient with multiple chronic diseases, complex histories of the present illness, and customized treatment plans. On the other hand, dictation can be incorporated into all or parts of the EHR record but the resulting narrative is usually unsatisfactory for meeting the ultimate goal of having structured, computable documentation needed for such diverse uses as CDS, Quality Measure computations, clinical research, and population and public health reporting. 3) Quality Reporting. The IFR for Meaningful Use focuses a lot of attention on quality reporting. Whether individual EHRs will best be able to provide all the quality measure outputs or whether use of an intermediary dedicated to extracting the data from the EHR and then calculating the measures will be the direction to go remains to be determined. Finding ways to perform the requirements automatically, in the background, with accurate results is what clinicians need. 4) Reconciliation. Clinicians must reconcile numerous types of information-problem lists, medication lists, allergies, and outside medical records to name just a few. Many of these tasks are amenable to automation to help reduce clinician workload. I haven't heard much about the reconciliation challenge at conferences but I expect it to move up in prominence during the next few years. Fitting reconciliation tasks into clinician workflows is not easy. 5) Health Information Exchange (HIE.) One of the thrusts of the IFR for Meaningful Use is to increase the private and secure exchange of health care information among the various stakeholders. Relatively few health information exchanges are up and running in the U.S. Clinicians will have to learn how to incorporate health information exchange into their workflows, in the least disruptive manner. Some of these exchanges may take place synchronously but most will probably be asynchronous. We also don't yet know what flavor of HIE will work best. Point-to-point seems most simple but requires knowledge of the recipient's contact information. Exchange of information within a network has satisfactory standards for guidance and a number of successful demonstration sites exist. The network of networks concept of early versions of the NHIN seems to be evolving. The effect on workflow is difficult to discern because the technology is so immature at this point.
Workflow effects of information technology in health care are important. I am sure we will be hearing more and more about this topic in the coming years.
Augmented productivity, improved safety or quality of medical care. 1) Order sets. Clinicians learn to write orders from day one in their clinical training. Ordering is a major process used to provide medical care. The use of order sets has many advantages over handwritten orders. First, teams of clinicians come together to design the order set and try to incorporate best practices from their own experiences and recent medical literature. For the clinician at the point of care, it is possible to "write" lengthy orders with just one or several clicks of the mouse. For recipients of orders, they are concise and legible, and standardized. For patients, order sets may assure that they are receiving the best care possible. 2) Electronic prescribing (eRx). A number of published studies have shown the efficacy of eRx in increasing the efficiency of care, minimizing medical errors caused by poor legibility of handwritten prescriptions, similarity of certain drug names, and incorrect dosing decisions. The ambulatory office workflows with eRx, especially for prescription renewals, can greatly increase clinician efficiency. As information exchanges grow, formulary checking and optimization present the potential of time and money savings for all. A thorny issue for the workflow of electronic prescribers has been the regulatory prohibition against the use of eRx for controlled substances. The FDA should be publishing an interim final rule (IFR) on this topic in the Federal Register today (preliminary document can be found here.) This long-awaited rule should help eliminate one of the major barriers to more wide-spread adoption of eRx. 3) Simple Decision Support. Alerts and reminders, when thoughtfully implemented, have been shown to improve the safety and quality of care, especially with respect to the medication ordering process. Already, innumerable errors have been prevented where drug-drug, drug-allergy, or drug-disease checking are performed automatically. These alerts fit perfectly into the clinical workflow because they appear while the drug ordering process is underway. I will discuss the more complex forms of clinical decision support below.
Examples where the workflow effects have primarily been detrimental in the clinical environment. 1) When the clinician moves quickly from one geographical point of service to another. Provider access to computer workstations and other hardware remains problematic. Clinicians continue to complain about the barriers created by security and privacy policies and procedures. Usernames and frequently changing passwords are a source of frustration. Use of single sign-on methods help but still are not a panacea. Furthermore, there is a trend toward true two factor authentication (see requirements in electronic prescribing of controlled substances rule above) in health care systems that may exacerbate the problem. Smart cards, proximity cards and biometric techniques may help mitigate clinician frustration. Somehow, I believe a technical solution to this conundrum will be developed in the future. 2) Infrequent tasks. It is human nature to forget how perform tasks that are done infrequently. It can be more difficult to create electronic orders for treatments that don't fit neatly into order sets. Good initial and recurrent training, superuser availability, and access to effective help assets-help desks, help menus, online-on-demand training, can all serve to limit clinician dissatisfaction.
Examples with variable, questionable or unknown effects. 1) Advanced Clinical Decision Support. This flavor of CDS usually addresses the more complex scenarios involved in acute and chronic disease management. CDS here is usually implemented through the use of structured order sets. The workflow challenge is to automatically deliver needed information to the clinician when and where needed (or at least make manual access to detailed information simple and imbedded in the same application.) Another difficulty is integration of CDS systems and EHRs. The correct data need to be collected and stored in the EHR to enable maximum CDS utility. Strategically placed info buttons allow clinicians to drill deeper for detailed information and to examine the original sources for evidence-based guidelines. Another challenge is the use of diagnostic decision support. When the diagnosis of a patient's condition is not known, then use of diagnostic CDS is an obvious course of action. Here the problem is making sure that enough of the correct data from history, physical, laboratory studies, radiology, and other studies is available to the CDS system so that it can provide a list of diagnoses that has a high probability of containing the one that is correct. Another problem for diagnostic CDS is that it cannot be helpful unless the clinician activates it. If a clinician decides to treat a patient based on an incorrect diagnosis, then the patient is not likely to get better. The difficulty for the clinician is knowing what you don't know. Here is a good example. A colleague of mine treated a patient with a large blister on the inner side of his foot with antibiotics and surgery. He thought it was an infection. Later, he asked me to consult because I had special training in foot and ankle surgery. I reviewed the patient's chart and I noted there was a history of regional enteritis and in fact the patient had a small fistula from the bowel to his abdominal wall. The photograph of the initial skin lesion looked like a bullous to me. There are relatively few conditions that manifest with bullous-like skin lesions. A quick check on the Internet yielded the correct diagnosis-pyoderma gangrenosum-a skin condition associated with inflammatory bowel disease that requires treatment with high dose steroids. This is a medication we would not use to treat infections. As a clinician there is always the fear-how do you know what you don't know? 2) Clinical Documentation. Many clinicians find documentation to be more difficult and slower with EHR technology than with traditional paper-based record keeping methods. Often, clinicians use keyboard entry of data but a large proportion finds this method to be slow, awkward, and intrusive. Template driven documentation can be efficient in some settings but is difficult to use for more nuanced requirements of treating a patient with multiple chronic diseases, complex histories of the present illness, and customized treatment plans. On the other hand, dictation can be incorporated into all or parts of the EHR record but the resulting narrative is usually unsatisfactory for meeting the ultimate goal of having structured, computable documentation needed for such diverse uses as CDS, Quality Measure computations, clinical research, and population and public health reporting. 3) Quality Reporting. The IFR for Meaningful Use focuses a lot of attention on quality reporting. Whether individual EHRs will best be able to provide all the quality measure outputs or whether use of an intermediary dedicated to extracting the data from the EHR and then calculating the measures will be the direction to go remains to be determined. Finding ways to perform the requirements automatically, in the background, with accurate results is what clinicians need. 4) Reconciliation. Clinicians must reconcile numerous types of information-problem lists, medication lists, allergies, and outside medical records to name just a few. Many of these tasks are amenable to automation to help reduce clinician workload. I haven't heard much about the reconciliation challenge at conferences but I expect it to move up in prominence during the next few years. Fitting reconciliation tasks into clinician workflows is not easy. 5) Health Information Exchange (HIE.) One of the thrusts of the IFR for Meaningful Use is to increase the private and secure exchange of health care information among the various stakeholders. Relatively few health information exchanges are up and running in the U.S. Clinicians will have to learn how to incorporate health information exchange into their workflows, in the least disruptive manner. Some of these exchanges may take place synchronously but most will probably be asynchronous. We also don't yet know what flavor of HIE will work best. Point-to-point seems most simple but requires knowledge of the recipient's contact information. Exchange of information within a network has satisfactory standards for guidance and a number of successful demonstration sites exist. The network of networks concept of early versions of the NHIN seems to be evolving. The effect on workflow is difficult to discern because the technology is so immature at this point.
Workflow effects of information technology in health care are important. I am sure we will be hearing more and more about this topic in the coming years.
Thursday, March 18, 2010
Thoughts on the NHIN
One of the hot button items at HIMSS10 concerned the NHIN. There were a number of educational sessions that had NHIN related content and the Interoperability Showcase seemed abuzz with the Federal Health Architecture and NHIN. Significant Showcase floor space was dedicated to the NHIN. I'm sure it was significant that the ONC had a nearby booth as well. I have tried hard to come up to speed on the NHIN but not all facets are clear to me. My initial impression was that it is a gargantuan government supported HIE. But there is not just one NHIN. First, let's look at some of the meaningful use requirements that may necessitate information exchange.
Health Care Policy 1. Improving quality, safety, efficiency and reducing health disparities.
Care Goals:
1. Provide access to comprehensive patient health data for patient's health care team
2. Generate information for quality improvement and public reporting
Stage 1 objectives:
1. incorporate clinical lab-test results into EHR as structured data
2. generate lists of patients by specific conditions to use for quality improvement, reduction of disparities, and outreach
3. report quality measures to CMS or the states
4. send reminders to patients per patient preference for preventive/follow-up care
5. check insurance eligibility electronically from public and private payers
6. submit claims electronically to public and private payers
7. generate and transmit permissible prescriptions electronically (eRx)
Health Care Policy 2.Engage patients and families in their healthcare
Care Goals:
1. Provide patients and families with timely access to data, knowledge, and tools to make informed decisions and to manage their health
Stage 1 objectives:
1. provide patients with an electronic copy of their health information (including diagnostic test results, problem lists, medication lists, allergies) upon request
2. provide patients with an electronic copy of their hospital discharge instructions and procedures at time of discharge, upon request
3. provide patients with electronic access to their health information (including lab results, problem list, medication list, allergies) within 96 hours of the information being available to the EP
4. provide clinical summaries for patients for each office visit
Health Care Policy 3. Improve care coordination
Care Goals:
1. Exchange meaningful clinical information among professional health care team
Stage 1 objectives:
1. capability to exchange clinical key information (for example, problem list, medication list, allergies, diagnostic test results) among providers of care and patient authorized entities electronically
Health Care Policy 4. Improving population and public health
Care Goals:
1. Communicate with public health agencies
Stage 1 objectives:
1. capability to submit electronic data to immunization registries and actual submission where required and accepted
2. capability to provide electronic submission of reportable lab results (as required by state or local law) to public health agencies and actual submission where it can be received
3. capability to provide electronic syndromic surveillance data to public health agencies and actual transmission according to applicable law and practice
Health Care Policy 5. Ensure adequate privacy and security protections for personal health information
Care Goals:
1. Ensure privacy and security protections for confidential information through operating policies, procedures, and technologies in compliance with applicable law
2. Provide transparency of data sharing to patient
Stage 1 objectives:
1. Protect electronic health information created or maintained by the certified EHR technology through the implementation of appropriate technical capabilities
So you can see that each of the 5 health care policies for Meaningful Use requires information exchange beyond the boundaries of a single system. Health information exchange is a process that is foundational for Meaningful Use.
Next we will consider two models for information exchange. An excellent discussion of these two approaches may be found in a recent blog by Wes Rishel.
Point-to-point exchange in the medical realm requires secure transport. Also required are agreed standards for data elements/vocabulary, document /messaging, and a basic mechanism to manage patient consents. Users must know the contact information for their counterparts. Queries for information generally are not available or are not automated. So you can see that here ambitions are low and requirements are limited. Functional impact is potentially high for individual patients and organizations but the capability to positively affect the health of populations and our health care system in general is not present.
The NHIN solution for this approach is NHIN Direct-This project is a little over two weeks old. The goal is to bring together major stakeholders to identify the technology (open source preferred) and establish procedures for point-to-point health information sharing. The intent is to use a rapid development approach to arrive at an initial solution by this fall. Emphasis should be placed on the fact that NHIN Direct currently is just an idea- there is not a functioning network; there are no pilot projects to refer to; scalability of this approach to fulfill Meaningful Use requirements has not been tested. Nevertheless those involved in the project, as reported at HIMSS10, and recent webinars, are full of enthusiasm. I highly recommend the excellent webinar series sponsored by the National eHealth Collaborative to learn more about on-going developments.
Comprehensive information exchange offers a menu of possible services including directories for providers, payers, labs, and pharmacies; secure routing of messages/documents; electronic master patient index; aggregation services for public health or quality reporting; document storage via registries/repositories; user identity management and authorizations; audit trails; encryption services; data mapping/cleansing services; and comprehensive data use and reciprocal support agreements among the participants. The extant NHIN for comprehensive information exchange has 3 major components: 1) NHIN Technical Assets-these are the specifications, standards, registries, and testing tools, 2) NHIN Connect Gateway- this is open source software that uses the NHIN specifications, and 3) NHIN Exchange- members use the NHIN Gateway and have signed a common Data Use and Reciprocal Support (DURSA) agreement that establishes a trust framework for participants. Development of the DURSA was a major undertaking that involved multiple legal representatives from the participating organizations.
A number of NHIN Exchange pilot projects have been undertaken over the last few years. Most have involved a small number of partners with relatively limited and carefully defined data exchanges. The participants sound universally thrilled with their successes to date, and rightly so considering the numerous barriers involved. On the other hand, these have truly been pilot projects that are many orders of magnitude beneath the scale envisioned by the Meaningful Use requirements that will affect some organizations as early as this October. I am sobered by the reality.
Health Care Policy 1. Improving quality, safety, efficiency and reducing health disparities.
Care Goals:
1. Provide access to comprehensive patient health data for patient's health care team
2. Generate information for quality improvement and public reporting
Stage 1 objectives:
1. incorporate clinical lab-test results into EHR as structured data
2. generate lists of patients by specific conditions to use for quality improvement, reduction of disparities, and outreach
3. report quality measures to CMS or the states
4. send reminders to patients per patient preference for preventive/follow-up care
5. check insurance eligibility electronically from public and private payers
6. submit claims electronically to public and private payers
7. generate and transmit permissible prescriptions electronically (eRx)
Health Care Policy 2.Engage patients and families in their healthcare
Care Goals:
1. Provide patients and families with timely access to data, knowledge, and tools to make informed decisions and to manage their health
Stage 1 objectives:
1. provide patients with an electronic copy of their health information (including diagnostic test results, problem lists, medication lists, allergies) upon request
2. provide patients with an electronic copy of their hospital discharge instructions and procedures at time of discharge, upon request
3. provide patients with electronic access to their health information (including lab results, problem list, medication list, allergies) within 96 hours of the information being available to the EP
4. provide clinical summaries for patients for each office visit
Health Care Policy 3. Improve care coordination
Care Goals:
1. Exchange meaningful clinical information among professional health care team
Stage 1 objectives:
1. capability to exchange clinical key information (for example, problem list, medication list, allergies, diagnostic test results) among providers of care and patient authorized entities electronically
Health Care Policy 4. Improving population and public health
Care Goals:
1. Communicate with public health agencies
Stage 1 objectives:
1. capability to submit electronic data to immunization registries and actual submission where required and accepted
2. capability to provide electronic submission of reportable lab results (as required by state or local law) to public health agencies and actual submission where it can be received
3. capability to provide electronic syndromic surveillance data to public health agencies and actual transmission according to applicable law and practice
Health Care Policy 5. Ensure adequate privacy and security protections for personal health information
Care Goals:
1. Ensure privacy and security protections for confidential information through operating policies, procedures, and technologies in compliance with applicable law
2. Provide transparency of data sharing to patient
Stage 1 objectives:
1. Protect electronic health information created or maintained by the certified EHR technology through the implementation of appropriate technical capabilities
So you can see that each of the 5 health care policies for Meaningful Use requires information exchange beyond the boundaries of a single system. Health information exchange is a process that is foundational for Meaningful Use.
Next we will consider two models for information exchange. An excellent discussion of these two approaches may be found in a recent blog by Wes Rishel.
Point-to-point exchange in the medical realm requires secure transport. Also required are agreed standards for data elements/vocabulary, document /messaging, and a basic mechanism to manage patient consents. Users must know the contact information for their counterparts. Queries for information generally are not available or are not automated. So you can see that here ambitions are low and requirements are limited. Functional impact is potentially high for individual patients and organizations but the capability to positively affect the health of populations and our health care system in general is not present.
The NHIN solution for this approach is NHIN Direct-This project is a little over two weeks old. The goal is to bring together major stakeholders to identify the technology (open source preferred) and establish procedures for point-to-point health information sharing. The intent is to use a rapid development approach to arrive at an initial solution by this fall. Emphasis should be placed on the fact that NHIN Direct currently is just an idea- there is not a functioning network; there are no pilot projects to refer to; scalability of this approach to fulfill Meaningful Use requirements has not been tested. Nevertheless those involved in the project, as reported at HIMSS10, and recent webinars, are full of enthusiasm. I highly recommend the excellent webinar series sponsored by the National eHealth Collaborative to learn more about on-going developments.
Comprehensive information exchange offers a menu of possible services including directories for providers, payers, labs, and pharmacies; secure routing of messages/documents; electronic master patient index; aggregation services for public health or quality reporting; document storage via registries/repositories; user identity management and authorizations; audit trails; encryption services; data mapping/cleansing services; and comprehensive data use and reciprocal support agreements among the participants. The extant NHIN for comprehensive information exchange has 3 major components: 1) NHIN Technical Assets-these are the specifications, standards, registries, and testing tools, 2) NHIN Connect Gateway- this is open source software that uses the NHIN specifications, and 3) NHIN Exchange- members use the NHIN Gateway and have signed a common Data Use and Reciprocal Support (DURSA) agreement that establishes a trust framework for participants. Development of the DURSA was a major undertaking that involved multiple legal representatives from the participating organizations.
A number of NHIN Exchange pilot projects have been undertaken over the last few years. Most have involved a small number of partners with relatively limited and carefully defined data exchanges. The participants sound universally thrilled with their successes to date, and rightly so considering the numerous barriers involved. On the other hand, these have truly been pilot projects that are many orders of magnitude beneath the scale envisioned by the Meaningful Use requirements that will affect some organizations as early as this October. I am sobered by the reality.
Monday, March 15, 2010
Summary of HIT Policy Committee Workgroup hearing on EHR Safety.
The certification and Implementation Work Group of the HIT Policy Committee met recently to discuss EHR safety issues. See my previous post on February 21, 2010 in which I discussed some of the aspects of EHR safety before the committee met. I had been planning to discuss the topic for a long time before I learned that the committee had scheduled a meeting dedicated to the safety issue. I will review my impressions of the testimony presented to the committee in this post.
Issue 1: Training. Potential safety issues arise because of the reluctance of clinicians to take the time out from busy and productive patient care for adequate training in the use of EHR systems. This must be understood in the context of the financial stresses on the medical profession, including decreasing reimbursements for clinical care and steadily and rapidly increasing operating expenses. An additional factor may be the impression of many clinicians that EHRs do not increase the practitioner's practice efficiency.
Many of the mature clinicians went through training before EHRs became wide-spread in academic centers so they have little experience using technology for clinical care. This results in a gap in technology aptitude between recently trained and more established clinicians. Another factor is the paucity of well trained educators at higher levels to provide training to clinicians that need it. There is a great need to educate the workforce in informatics at master's degree and PhD levels to support clinical research, public health, and other academic activities.
Issue 2: Error Reporting. An intense discussion was held about error reporting. Published reports on the safety of EHRs are contradictory. The mechanisms for safety reporting varies from state. The NASA ASRS system of the aviation industry should serve as the model for medicine. Characteristics include: anonymous error reporting, a culture that promotes learning from human error rather than punishment, and a third party that collects, aggregates, and distills accident information and then distributes the lessons learned throughout the industry. There was a lot of disagreement about whether error reporting should be voluntary or mandatory. One EHR vendor reports errors voluntarily to the FDA through MedWatch. Likewise, there was controversy about whether reporting should be confidential (as per the FAA program) or public (perhaps more transparent but also potentially more punitive.) Experience has shown that when public reporting programs are used, errors tend to be reported less often.
One regulatory barrier is the differences in reporting requirements at the state and federal level. Each state has its own requirements that generally take precedence over federal regulations. A federal law took effect in 2005 that established Public Safety Organizations (PSOs) that are based on the concept of confidential reporting and protection from legal consequences in most situations. Many members of the committee did not seem to understand fully how PSOs operate.
The possible role of "I'm Sorry" programs also was discussed. Apologizing to patients and their families when errors occur in medical practice has generally been shown to reduce the risk that the issue will be resolved as a tort case. On the other hand, regulations vary from state to state as do legal protections that are sometimes offered with these programs.
Issue #3. Vendor response to reported errors. Several of the vendors denied accusations of complacency in responding to errors in software design reported by their clients. They asserted that the vendor community is anxious to design and build safe EHR systems. It is likely that the major vendors take a proactive approach to dealing with any reported flaws in the software they market. How some of the less successful vendors respond to problems might be open to question.
Issue #4. FDA Role. The FDA representative spoke at length about the FDA role in monitoring EHR systems. The FDA classifies EHRs as medical devices and therefore they fall under its authority and responsibility. So far this authority has just not been exercised. That is not to say that it will not be used in the future. Pre-market oversight has the potential to significantly impact vendors by extending the length of time required to develop new products and increasing the costs of compliance. A new policy could critically impact the capability of vendors to deliver new products needed to fulfill the escalating meaningful use criteria in the new few years.
The FDA does not have a formal infrastructure in place to handle reports of unsafe EHR software. However it does accept voluntary error reports. A mandatory reporting program has not been instituted. Furthermore, unlike the situation in the aviation industry, a program to analyze reports, extract significant findings, and propagate best practices has not been developed.
Safety Issue #5. Safety of "home-grown" vs. vendor systems. Proponents of self-developed systems claim they have many years experience tweaking their EHRs. They have developed the specialized workforce needed to quickly identify, locate, and solve patient safety-related issues. Critics of the home-grown approach note that these systems have often been cobbled together from disparate subsystems over time. Coordinating these different systems via interfaces creates new possibilities for errors caused by the software. Several examples were mentioned.
Vendor created systems are usually fully integrated. They are less likely to cause the types of errors that arise from mismatched subsystems. (This is not always true because many companies have been formed by mergers and acquisitions so multiple components are often melded into a single, branded product.) A criticism of vendors is that because of the difficulty of migrating from one vendor to another there is a "locked-in" situation for the clients. The reasoning goes that vendors would not need to quickly respond to client issues. Realistically, a vendor selling a product that is not safe would not long survive in the active EHR marketplace. Even "out-of-the-box" systems are extensively customized to each installation site. The more customized these systems are, the greater the risk of unanticipated patient safety issues. Vendors may favor standardized implementations to minimize these risks but they still must respond to client demands for highly customized systems.
Issue #6. Certification testing. Several participants discussed the expected NPRM concerning certification. (The NPRM was released on March 2nd and published in the Federal Register on March 10th after the meeting.) Some committee members argued that site specific certification should be required even for vendor supplied products. Site specific testing was mentioned as a way to address the risks that customization introduces into the equation. No one explained how literally thousands of installations would be tested, what type of site-specific certification tests would be needed, and who would bear the costs for specific site testing of all EHRs. I don't think that data has been provided to support establishment of such an extensive program.
The following links are the actual reports and recommendations that the WG presented to the HIT Policy Committee on March 17, 2010.
Issue 1: Training. Potential safety issues arise because of the reluctance of clinicians to take the time out from busy and productive patient care for adequate training in the use of EHR systems. This must be understood in the context of the financial stresses on the medical profession, including decreasing reimbursements for clinical care and steadily and rapidly increasing operating expenses. An additional factor may be the impression of many clinicians that EHRs do not increase the practitioner's practice efficiency.
Many of the mature clinicians went through training before EHRs became wide-spread in academic centers so they have little experience using technology for clinical care. This results in a gap in technology aptitude between recently trained and more established clinicians. Another factor is the paucity of well trained educators at higher levels to provide training to clinicians that need it. There is a great need to educate the workforce in informatics at master's degree and PhD levels to support clinical research, public health, and other academic activities.
Issue 2: Error Reporting. An intense discussion was held about error reporting. Published reports on the safety of EHRs are contradictory. The mechanisms for safety reporting varies from state. The NASA ASRS system of the aviation industry should serve as the model for medicine. Characteristics include: anonymous error reporting, a culture that promotes learning from human error rather than punishment, and a third party that collects, aggregates, and distills accident information and then distributes the lessons learned throughout the industry. There was a lot of disagreement about whether error reporting should be voluntary or mandatory. One EHR vendor reports errors voluntarily to the FDA through MedWatch. Likewise, there was controversy about whether reporting should be confidential (as per the FAA program) or public (perhaps more transparent but also potentially more punitive.) Experience has shown that when public reporting programs are used, errors tend to be reported less often.
One regulatory barrier is the differences in reporting requirements at the state and federal level. Each state has its own requirements that generally take precedence over federal regulations. A federal law took effect in 2005 that established Public Safety Organizations (PSOs) that are based on the concept of confidential reporting and protection from legal consequences in most situations. Many members of the committee did not seem to understand fully how PSOs operate.
The possible role of "I'm Sorry" programs also was discussed. Apologizing to patients and their families when errors occur in medical practice has generally been shown to reduce the risk that the issue will be resolved as a tort case. On the other hand, regulations vary from state to state as do legal protections that are sometimes offered with these programs.
Issue #3. Vendor response to reported errors. Several of the vendors denied accusations of complacency in responding to errors in software design reported by their clients. They asserted that the vendor community is anxious to design and build safe EHR systems. It is likely that the major vendors take a proactive approach to dealing with any reported flaws in the software they market. How some of the less successful vendors respond to problems might be open to question.
Issue #4. FDA Role. The FDA representative spoke at length about the FDA role in monitoring EHR systems. The FDA classifies EHRs as medical devices and therefore they fall under its authority and responsibility. So far this authority has just not been exercised. That is not to say that it will not be used in the future. Pre-market oversight has the potential to significantly impact vendors by extending the length of time required to develop new products and increasing the costs of compliance. A new policy could critically impact the capability of vendors to deliver new products needed to fulfill the escalating meaningful use criteria in the new few years.
The FDA does not have a formal infrastructure in place to handle reports of unsafe EHR software. However it does accept voluntary error reports. A mandatory reporting program has not been instituted. Furthermore, unlike the situation in the aviation industry, a program to analyze reports, extract significant findings, and propagate best practices has not been developed.
Safety Issue #5. Safety of "home-grown" vs. vendor systems. Proponents of self-developed systems claim they have many years experience tweaking their EHRs. They have developed the specialized workforce needed to quickly identify, locate, and solve patient safety-related issues. Critics of the home-grown approach note that these systems have often been cobbled together from disparate subsystems over time. Coordinating these different systems via interfaces creates new possibilities for errors caused by the software. Several examples were mentioned.
Vendor created systems are usually fully integrated. They are less likely to cause the types of errors that arise from mismatched subsystems. (This is not always true because many companies have been formed by mergers and acquisitions so multiple components are often melded into a single, branded product.) A criticism of vendors is that because of the difficulty of migrating from one vendor to another there is a "locked-in" situation for the clients. The reasoning goes that vendors would not need to quickly respond to client issues. Realistically, a vendor selling a product that is not safe would not long survive in the active EHR marketplace. Even "out-of-the-box" systems are extensively customized to each installation site. The more customized these systems are, the greater the risk of unanticipated patient safety issues. Vendors may favor standardized implementations to minimize these risks but they still must respond to client demands for highly customized systems.
Issue #6. Certification testing. Several participants discussed the expected NPRM concerning certification. (The NPRM was released on March 2nd and published in the Federal Register on March 10th after the meeting.) Some committee members argued that site specific certification should be required even for vendor supplied products. Site specific testing was mentioned as a way to address the risks that customization introduces into the equation. No one explained how literally thousands of installations would be tested, what type of site-specific certification tests would be needed, and who would bear the costs for specific site testing of all EHRs. I don't think that data has been provided to support establishment of such an extensive program.
The following links are the actual reports and recommendations that the WG presented to the HIT Policy Committee on March 17, 2010.
Sunday, March 7, 2010
Dr. Blumenthal--An Inspirational Keynote Address at HIMSS10
Dr. David Blumenthal presented the Keynote Address on Wednesday, March 3, at HIMSS10. Present was a standing room only audience eager to listen to his summary of efforts during a very busy first year in office. It is not an exaggeration to say that the audience listened with rapt, respectful attention. No one walked out of the room during the talk. I don't even recall anyone in the audience coughing. I personally felt touched by the unusually emotional presentation.
During the majority of the talk Dr. Blumenthal appeared almost somber, reserved. I think I mistook this mood which more likely represented seriousness and focus. The key point was that all the efforts of the Office of the National Coordinator have been addressed at achieving transformational social change rather than the more mundane task of simply supporting the installation of technology. His dedication to the promotion of personal and population health in this country via established scientific underpinnings of health IT was unmistakable. This is one venue where health care reform is not waiting for a supportive congressional vote.
Facing a possible role as a chief medical information officer (CMIO) I have been on the look out for convincing arguments to promote changes in physician behavior needed for the successful adoption of health IT. Dr. Blumenthal provided the most apt reason for clinicians to move forward with health IT—Professionalism. As clinicians we have committed our life's professional efforts to improving the health of our patients. Resisting the use of health IT would therefore be interpreted as a denial of our responsibilities. Peer pressure and the natural competitiveness of physicians should be harnessed to move the process forward. I expect the Accreditation Council for Graduate Medical Education ACGME to establish explicit requirements that residents understand and be capable of using medical informatics to advance the health care of patients. I think this is so important that it should be added as a new requirement to the current list of core competencies. Specialty boards will incorporate similar requirements for both initial board certification and recertification.
The first year of work has been consumed by the development of policies and regulations demanded by the 2009 ARRA legislation. The ONC will now be transitioning to an era of policy implementation. Most of the $2 billion allotted by Congress for the ONC have now been committed to various programs. Some of the most difficult work lies ahead. Complying with congressional timelines will be especially challenging.
Toward the end of the talk Dr. Blumenthal appeared to relax. He declared his own optimism for the future. I left the auditorium with the conviction that the talk was not just political rhetoric. I hope you all had the chance to listen to this speech. I know it will serve as an inspirational reference for me as I face tough moments in my new career during the next few years.
During the majority of the talk Dr. Blumenthal appeared almost somber, reserved. I think I mistook this mood which more likely represented seriousness and focus. The key point was that all the efforts of the Office of the National Coordinator have been addressed at achieving transformational social change rather than the more mundane task of simply supporting the installation of technology. His dedication to the promotion of personal and population health in this country via established scientific underpinnings of health IT was unmistakable. This is one venue where health care reform is not waiting for a supportive congressional vote.
Facing a possible role as a chief medical information officer (CMIO) I have been on the look out for convincing arguments to promote changes in physician behavior needed for the successful adoption of health IT. Dr. Blumenthal provided the most apt reason for clinicians to move forward with health IT—Professionalism. As clinicians we have committed our life's professional efforts to improving the health of our patients. Resisting the use of health IT would therefore be interpreted as a denial of our responsibilities. Peer pressure and the natural competitiveness of physicians should be harnessed to move the process forward. I expect the Accreditation Council for Graduate Medical Education ACGME to establish explicit requirements that residents understand and be capable of using medical informatics to advance the health care of patients. I think this is so important that it should be added as a new requirement to the current list of core competencies. Specialty boards will incorporate similar requirements for both initial board certification and recertification.
The first year of work has been consumed by the development of policies and regulations demanded by the 2009 ARRA legislation. The ONC will now be transitioning to an era of policy implementation. Most of the $2 billion allotted by Congress for the ONC have now been committed to various programs. Some of the most difficult work lies ahead. Complying with congressional timelines will be especially challenging.
Toward the end of the talk Dr. Blumenthal appeared to relax. He declared his own optimism for the future. I left the auditorium with the conviction that the talk was not just political rhetoric. I hope you all had the chance to listen to this speech. I know it will serve as an inspirational reference for me as I face tough moments in my new career during the next few years.
Saturday, March 6, 2010
Dr. Bob HIT Thoughts Blog Index
Breach Notification-Part 1 Oct. 15, 2009
Breach Notification-Part 2 Oct. 26, 2009
Certification July 29, 2009
Certification Follow-up Aug. 19, 2009
Consumer Preferences Nov. 2, 2009
EHR Safety Feb. 21, 2010
EMR Certification Revisited Nov. 17, 2009
EMR Usability Nov. 22, 2009
Future Role for HITSP? Dec. 2, 2009
Handheld Devices-the Mobile Clinician Jan. 9, 2010
Health Information Exchange Aug. 18, 2009
Health IT Workforce Training Dec. 27, 2009
HIT Workforce Training Dec. 14, 2009
Introduction July 17, 2009
IFR on Standards and NPRM on Meaningful Use Feb. 16, 2010
Meaningful Use and Incentives to adopt HIT July 21, 2009
Online Education Sept.10, 2009
Online Graduate Degrees-My Experience Nov. 18, 2009
Quality Reporting Sept. 30, 2009
Reconciliation-an unmet Challenge Sept. 14, 2009
Breach Notification-Part 2 Oct. 26, 2009
Certification July 29, 2009
Certification Follow-up Aug. 19, 2009
Consumer Preferences Nov. 2, 2009
EHR Safety Feb. 21, 2010
EMR Certification Revisited Nov. 17, 2009
EMR Usability Nov. 22, 2009
Future Role for HITSP? Dec. 2, 2009
Handheld Devices-the Mobile Clinician Jan. 9, 2010
Health Information Exchange Aug. 18, 2009
Health IT Workforce Training Dec. 27, 2009
HIT Workforce Training Dec. 14, 2009
Introduction July 17, 2009
IFR on Standards and NPRM on Meaningful Use Feb. 16, 2010
Meaningful Use and Incentives to adopt HIT July 21, 2009
Online Education Sept.10, 2009
Online Graduate Degrees-My Experience Nov. 18, 2009
Quality Reporting Sept. 30, 2009
Reconciliation-an unmet Challenge Sept. 14, 2009
Subscribe to:
Posts (Atom)
Posts
