Health care information exchange is one of the elements of health information technology that offers the promise of transforming health care systems to improve patient care. But health information exchange cannot occur without standards-based interoperability. The adoption of standards allows disparate vendors to develop software that collects, stores, and communicates information without change in its integrity and meaning. One of the problems I have seen in working with HITSP and IHE is that many standards contain a lot of optionality when it comes to data elements. I think excessive optionality built into standards makes the goal of interoperability more challenging.
Here is how I encountered the optionality problem. I have worked as a monitor at the last two U.S. IHE Connectathons. As a monitor for the Patient Care Coordination (PCC) domain, I checked on the ability of vendors to use IHE profiles to exchange CDA documents/medical summaries. Before the Connectathon, clinical subject matter experts (SMEs) created the content that vendors were expected to include in their documents. My job started with automated validation of the CDA documents using a tool developed by NIST. A second step required a comparison of the actual data produced versus the script created by the SMEs. It's fair to say that most vendors did not produce and exact copy of the vendor script, even though these scripts contained very basic-information such as problems, medications, allergies, etc. So what is the explanation?
To find part of the answer requires a dive into the IHE profiles. In IHE, there are 3 options for the use of specific data elements. They are R-required, R2-required if known, and O-optional. This opens the door for interpretation by users as what to include in the document, under what circumstances. At the Connectathon this resulted in a lot of consternation for me. I thought if a profile allows so many interpretations in a very restricted testing environment, how would it perform in real world use? Interestingly, HITSP used similar optionality choices in its data definition tables. One of the added values that standards harmonization organizations should bring to the standards world is constraint of the optionality offered by base standards. There must be some use for optionality.
Optionality allows entities of different sizes and needs to interoperate. This enables a one-size-fits-all approach to standards development and interoperability. This enables scaling of applications according to business needs. Organizations with limited needs just don't utilize the built-in optionality. Optionality can also avoid hard stops when information is not initially known but may become know or change at a later time. An example would be a patient registration application that enables the emergency registration of a patient when the only demographic information available may be the patient's "trauma name." A good discussion of hard stops starts on page 13 of "Developing Successful Healthcare Software:10 Critical Lessons"
The down side of optionality is that it may degrade interoperability. Further, based on my experience, it may be more difficult and test software where there many optional data elements. One approach would be for standards development organizations (SDOs) to concentrate on the description of a minimum necessary data set for a given purpose or application and then limit optionality as much as possible.
There may be a number of causes for the optionality problem. SDOs should make sure to engage all the key stakeholders and secure their input when they set about developing new health care technology standards. Also, the democratic approach to the vetting and acceptance of standards in organizations such as SDOs may allow an outspoken majority to overrule the contributions of a minority group that has a better vision of the long-term consequences of some development decisions.
Monday, December 6, 2010
Wednesday, December 1, 2010
Planning for HIMSS 11
I recently went online to take advantage of early bird registration for HIMSS 11. This annual HIMSS meeting will take place in Orlando in February. I had put off registering because mostly because I had a really hard time deciding on one of the many pre-conference workshops or symposia offered this winter. Last year I attended the Physician's IT Symposium. There was a lot of good information and I felt I got my money's worth. This year I thought I would try something different. The problem was that there are too many good topics to choose from. I would like to have about 5 clones to attend the conference with me.
There will be a Clinical Decision Support workshop that will focus on CDS and its intersection with quality improvement. I think that innovative developments in CDS will be a focus for vendors of EHR software in the next five years. Use of evidence-based medicine guidelines baked into CDS will inevitably lead to more standardized, high-quality health care across the country.
Another option is the Change Management Workshop. No one can be knowledgeable enough about change management in this era of rapid adoption of technology. As many have discovered, "it's not about technology, it's about people." Despite our best wishes, people are reluctant to change their ways. This is particularly true of many older clinicians who are hoping to retire before all the changes on the horizon in medicine become reality. But, it is also true of people of all ages engaged in the health care enterprise.
One workshop that was hard for me to pass up was Life in the Fast Lane-Privacy and Security in the Age of the Electronic Health Record. Privacy and security issues are among the top concerns of both consumers and clinicians. Health information exchange is mandated in Meaningful Use regulations. Progress will be difficult unless the health IT community can assure the confidentiality, integrity, and availability of personal health information in a framework of trust during information exchange. I will never know as much as I would like about the topic of privacy and security.
The HIE in the Era of HITECH and Health Reform Symposium is another session I would really like to attend. Health information exchange is one of technologies that will revolutionize the practice of medicine in the coming years. Getting it right will not be easy. The technological challenges, though daunting, will take a back seat to issues of governance, policy, and consent. I am in favor of a central approach. The federal government, through the state grant program, is favoring a more federated landscape. Both flavors of information will be supported. Purpose of use will probably determine which method is best in a given situation.
Closely aligned with HIE is the Secondary Use of Data Symposium. I was so interested in the topic of secondary use that I chose to make it a focus of one of the major papers I completed in one of my master's degree classes. My short essay of 35 pages just scratched the surface of this subject that cuts across many domains in health IT.
So I chose the ARRA Usability Symposium of all the possibilities. I made this decision, not because I think it is the most interesting to me. From a clinician's point of view it may be the most important however. Also, it is somewhat difficult to get good information about usability. I believe that usability issues have been a major factor that has slowed the adoption of EHR technology by clinicians. While human factors engineering has been applied with great success in fields such as aviation, it has been under utilized by EHR developers. I think one solution is greater collaboration between clinicians and the engineering community. I hope this symposium will provide some tools to help me pull my weight.
There will be a Clinical Decision Support workshop that will focus on CDS and its intersection with quality improvement. I think that innovative developments in CDS will be a focus for vendors of EHR software in the next five years. Use of evidence-based medicine guidelines baked into CDS will inevitably lead to more standardized, high-quality health care across the country.
Another option is the Change Management Workshop. No one can be knowledgeable enough about change management in this era of rapid adoption of technology. As many have discovered, "it's not about technology, it's about people." Despite our best wishes, people are reluctant to change their ways. This is particularly true of many older clinicians who are hoping to retire before all the changes on the horizon in medicine become reality. But, it is also true of people of all ages engaged in the health care enterprise.
One workshop that was hard for me to pass up was Life in the Fast Lane-Privacy and Security in the Age of the Electronic Health Record. Privacy and security issues are among the top concerns of both consumers and clinicians. Health information exchange is mandated in Meaningful Use regulations. Progress will be difficult unless the health IT community can assure the confidentiality, integrity, and availability of personal health information in a framework of trust during information exchange. I will never know as much as I would like about the topic of privacy and security.
The HIE in the Era of HITECH and Health Reform Symposium is another session I would really like to attend. Health information exchange is one of technologies that will revolutionize the practice of medicine in the coming years. Getting it right will not be easy. The technological challenges, though daunting, will take a back seat to issues of governance, policy, and consent. I am in favor of a central approach. The federal government, through the state grant program, is favoring a more federated landscape. Both flavors of information will be supported. Purpose of use will probably determine which method is best in a given situation.
Closely aligned with HIE is the Secondary Use of Data Symposium. I was so interested in the topic of secondary use that I chose to make it a focus of one of the major papers I completed in one of my master's degree classes. My short essay of 35 pages just scratched the surface of this subject that cuts across many domains in health IT.
So I chose the ARRA Usability Symposium of all the possibilities. I made this decision, not because I think it is the most interesting to me. From a clinician's point of view it may be the most important however. Also, it is somewhat difficult to get good information about usability. I believe that usability issues have been a major factor that has slowed the adoption of EHR technology by clinicians. While human factors engineering has been applied with great success in fields such as aviation, it has been under utilized by EHR developers. I think one solution is greater collaboration between clinicians and the engineering community. I hope this symposium will provide some tools to help me pull my weight.
Friday, November 19, 2010
EHR's for surgeons/specialists
John Halamka published an interesting blog on Tuesday, November 16 concerning some of the challenges of EHR use for surgeon practices. Some of his comments were spot on. Others engender further comment. I think many of Dr. Halamka's observations could be extended to the entire spectrum of medical and surgical specialists.
1. Surgeons do tend to treat patients who require relatively short term episodes of care rather than numerous patients needing long-term management of chronic diseases. Surgeons see their patients frequently, though over a time horizon of weeks or months but not often years.
2. Capturing useful and required clinical documentation, "getting it down" as my former mentor Dr. Mel Jahss called it, is a challenge for all clinicians. Template driven documentation, while often effective in primary care practices, is problematic in many surgeons' practices. Documenting the history and care plan for new patients often requires nuances that are difficult to capture with templates. Dictation has been a satisfactory but expensive solution. Informaticists however, eschew unstructured dictated notes in favor of structured documentation. Perhaps natural language processing will make it possible to generate a structured format useable for machine computing.
On the other hand, SOAP note templates for inpatient and outpatient follow-up visits can expedite documentation to save time and improve the quality of this type of documentation by increasing legibility and completeness of the note.
Four years ago in my practice, I gave an older version of Dragon a try for a year but found the results unsatisfactory. It was not possible to dictate and edit simultaneously. There were enough errors created by the software that editing was required to avoid embarrassment. I did not have the time to review every dictation in detail. Also, the technique for dictating in a voice recognition environment was quite different from using human transcriptionists who, when good, edit on the fly and clean up the dictation. I tried an online transcription service for awhile. The output was error-filled. I had a relatively low volume practice but ultimately found a local transcription service with a 24-48 hr turnaround time that cost $800-$1,200 per month for an excellent result.
Most surgeons do not use templates for their frequent procedures. There never seems to be the time to create templates even though they could save loads of time in the future. Here again, "getting it down" is the problem. I think surgeons would work collaboratively with clinical informaticists who sit down with them and help create templates for the three or four most frequent procedures. This service could be provided by implementation specialists for EHRs to promote process change. If you can prove to a surgeon you can improve practice efficiencies and save time needed to accomplish required tasks, they will gladly change and adopt health information technology. This is an area where a little hand-holding could go a long way to enhancing usability and physician satisfaction with electronic clinical documentation systems.
3. I think physicians climb a slippery slope when they decide to delegate tasks to mid-level personnel. Excessive use of such staff may contribute to decreased quality of care and patient dissatisfaction with the amount of time their physicians spend with them. I know I can take a much better history and perform a better physical than providers who have not been trained as physicians. I admit to my biases, as an orthopedic surgeon, based on numerous experiences dealing with unsatisfactory orthopedic care provided by untrained or poorly trained mid-level providers who are ubiquitous in urgent care centers and the less acute sides of emergency departments. I am in favor of the use of staff as scribes to "get it down." Mid-level staff can be trained to take vital signs and obtain past history (or abstract this information from a summary of care document.) I firmly believe that the physician is the best person to decide on the correct diagnosis and procedure codes. I also concede that inadequate resources have been devoted training residents in coding and other business process. Moreover, post-graduate physicians focus primarily on clinically oriented CME activities. This needs to change.
4. The development of interoperability and heath information exchange capabilities are as important to surgeons as primary care clinicians. As already mentioned, when clinical summaries become available from referring clinicians, the safety, efficiency, and timeliness of care will improve. Surgeons often need access to laboratory results for studies ordered by primary care providers. Having that information available through information exchange would save patients and the system by avoiding redundant testing. Furthermore, E-prescribing, which depends on information exchange, offers the same benefits to surgeons, other specialists and patients as it does for primary care clinicians.
Many types of specialists are increasingly dependent on imaging information to make diagnostic and treatment decisions. In many cases these images are stored by different service providers in silos that are difficult to access, even with the use DICOM and other imaging standards. Interestingly, the meaningful use initiative has not placed a high priority on imaging despite the explosion in the number of imaging studies now being performed. Imaging is barely mentioned until the Stage 3 proposals. Today, as an orthopedist I am still mostly provided either hard copy x-rays or digital images on portable media (CDs) by patients who had imaging studies outside my home institution. That is, if they remember to bring the "films" with them to their appointment. A few imaging providers offer access to their systems through proprietary portals but each requires downloaded software and separate logon credentials. I also want to emphasize that I need to see the actual pictures. A radiologist's report is never adequate in my line of work. I am sure this is true for other specialists as well. The ONC should adopt imaging standards and promote the exchange of imaging information in Meaningful Use stage 2 rather than waiting until 2015.
5. The ARRA legislation and Meaningful use requirements could have been written to be more supportive of surgeons/specialists. Primary care was the principal focus but this left out the majority of clinicians. Even the activities of the regional extension centers are structured to facilitate the adoption of EHRs by priority primary care practitioners and federally supported health centers rather than surgeons and other specialists. I don't understand how this approach has promoted the goal of achieving coordination of care and a more cohesive health care system in this country. Although some workflows and documentation requirements are different for primary care than surgeon/specialists, there are still considerable benefits for adoption of health information technology by the latter. For example, structured order sets/care plans can increase efficiency, productivity and consistency of care. Surgeons/specialists recognize the benefits that evidence-based guidelines offer. Incorporation of evidence-based treatment recommendations into order sets is a mechanism to insure that guidelines are followed. Also, many types of clinicians are looking at the use of registries to enhance individual and population health. Consider the total joint replacement registries currently in use by orthopedic surgeons. Registries also facilitate identifying patients affected by recall of medical devices/implants. Finally, I am convinced that clinical decision support developments will significantly modify clinician approach to diagnosis and treatment across the spectrum of patients. Realistically, CDS is difficult without the adoption and installation of EHR technology in physician practices and hospitals. INFO buttons incorporated into EHR software are the future for content aware search capabilities for clinicians.
1. Surgeons do tend to treat patients who require relatively short term episodes of care rather than numerous patients needing long-term management of chronic diseases. Surgeons see their patients frequently, though over a time horizon of weeks or months but not often years.
2. Capturing useful and required clinical documentation, "getting it down" as my former mentor Dr. Mel Jahss called it, is a challenge for all clinicians. Template driven documentation, while often effective in primary care practices, is problematic in many surgeons' practices. Documenting the history and care plan for new patients often requires nuances that are difficult to capture with templates. Dictation has been a satisfactory but expensive solution. Informaticists however, eschew unstructured dictated notes in favor of structured documentation. Perhaps natural language processing will make it possible to generate a structured format useable for machine computing.
On the other hand, SOAP note templates for inpatient and outpatient follow-up visits can expedite documentation to save time and improve the quality of this type of documentation by increasing legibility and completeness of the note.
Four years ago in my practice, I gave an older version of Dragon a try for a year but found the results unsatisfactory. It was not possible to dictate and edit simultaneously. There were enough errors created by the software that editing was required to avoid embarrassment. I did not have the time to review every dictation in detail. Also, the technique for dictating in a voice recognition environment was quite different from using human transcriptionists who, when good, edit on the fly and clean up the dictation. I tried an online transcription service for awhile. The output was error-filled. I had a relatively low volume practice but ultimately found a local transcription service with a 24-48 hr turnaround time that cost $800-$1,200 per month for an excellent result.
Most surgeons do not use templates for their frequent procedures. There never seems to be the time to create templates even though they could save loads of time in the future. Here again, "getting it down" is the problem. I think surgeons would work collaboratively with clinical informaticists who sit down with them and help create templates for the three or four most frequent procedures. This service could be provided by implementation specialists for EHRs to promote process change. If you can prove to a surgeon you can improve practice efficiencies and save time needed to accomplish required tasks, they will gladly change and adopt health information technology. This is an area where a little hand-holding could go a long way to enhancing usability and physician satisfaction with electronic clinical documentation systems.
3. I think physicians climb a slippery slope when they decide to delegate tasks to mid-level personnel. Excessive use of such staff may contribute to decreased quality of care and patient dissatisfaction with the amount of time their physicians spend with them. I know I can take a much better history and perform a better physical than providers who have not been trained as physicians. I admit to my biases, as an orthopedic surgeon, based on numerous experiences dealing with unsatisfactory orthopedic care provided by untrained or poorly trained mid-level providers who are ubiquitous in urgent care centers and the less acute sides of emergency departments. I am in favor of the use of staff as scribes to "get it down." Mid-level staff can be trained to take vital signs and obtain past history (or abstract this information from a summary of care document.) I firmly believe that the physician is the best person to decide on the correct diagnosis and procedure codes. I also concede that inadequate resources have been devoted training residents in coding and other business process. Moreover, post-graduate physicians focus primarily on clinically oriented CME activities. This needs to change.
4. The development of interoperability and heath information exchange capabilities are as important to surgeons as primary care clinicians. As already mentioned, when clinical summaries become available from referring clinicians, the safety, efficiency, and timeliness of care will improve. Surgeons often need access to laboratory results for studies ordered by primary care providers. Having that information available through information exchange would save patients and the system by avoiding redundant testing. Furthermore, E-prescribing, which depends on information exchange, offers the same benefits to surgeons, other specialists and patients as it does for primary care clinicians.
Many types of specialists are increasingly dependent on imaging information to make diagnostic and treatment decisions. In many cases these images are stored by different service providers in silos that are difficult to access, even with the use DICOM and other imaging standards. Interestingly, the meaningful use initiative has not placed a high priority on imaging despite the explosion in the number of imaging studies now being performed. Imaging is barely mentioned until the Stage 3 proposals. Today, as an orthopedist I am still mostly provided either hard copy x-rays or digital images on portable media (CDs) by patients who had imaging studies outside my home institution. That is, if they remember to bring the "films" with them to their appointment. A few imaging providers offer access to their systems through proprietary portals but each requires downloaded software and separate logon credentials. I also want to emphasize that I need to see the actual pictures. A radiologist's report is never adequate in my line of work. I am sure this is true for other specialists as well. The ONC should adopt imaging standards and promote the exchange of imaging information in Meaningful Use stage 2 rather than waiting until 2015.
5. The ARRA legislation and Meaningful use requirements could have been written to be more supportive of surgeons/specialists. Primary care was the principal focus but this left out the majority of clinicians. Even the activities of the regional extension centers are structured to facilitate the adoption of EHRs by priority primary care practitioners and federally supported health centers rather than surgeons and other specialists. I don't understand how this approach has promoted the goal of achieving coordination of care and a more cohesive health care system in this country. Although some workflows and documentation requirements are different for primary care than surgeon/specialists, there are still considerable benefits for adoption of health information technology by the latter. For example, structured order sets/care plans can increase efficiency, productivity and consistency of care. Surgeons/specialists recognize the benefits that evidence-based guidelines offer. Incorporation of evidence-based treatment recommendations into order sets is a mechanism to insure that guidelines are followed. Also, many types of clinicians are looking at the use of registries to enhance individual and population health. Consider the total joint replacement registries currently in use by orthopedic surgeons. Registries also facilitate identifying patients affected by recall of medical devices/implants. Finally, I am convinced that clinical decision support developments will significantly modify clinician approach to diagnosis and treatment across the spectrum of patients. Realistically, CDS is difficult without the adoption and installation of EHR technology in physician practices and hospitals. INFO buttons incorporated into EHR software are the future for content aware search capabilities for clinicians.
Monday, September 6, 2010
More thoughts on Documents
More on Documents
The HIT Standards Committee had an interesting meeting in June. One of the discussions concerned documents. It seemed to me that some of the committee members did not understand current document standards, based on some of the comments. Some of the best sources for information on health documents can be found in previous work by HITSP, IHE, and the standards development organization, HL7.
In discussing document standards, one of the committee members was critical of documents because of the challenges of interoperability with potentially an infinite number of documents. Realistically, in medicine, only a few dozen document types need to be available and are used by clinicians on a regular basis.
In my opinion, the most important document type needed to immediately improve patient care in the US is the patient care summary. This type of document is useful whenever there is a transition of care, in inpatient and ambulatory environments. An example would be when a patient is transferred from one unit to another or from the hospital to a long term care setting. Outpatient use of patient care summaries is needed when a patient is referred to a specialist, sent for special diagnostic studies, and when the patient is sent back to their primary care clinician for continued care. The patient care summary is essential for patient engagement in their health care and personal health information management and may be useful to help update PHRs.
HL7 (CDA 2.0 R2) and HITSP (C32) have well accepted standards and implementation guides for this document type, the CCD. This standard is one of those specified recently in the final standards regulations. Its alternative, the CCR serves the same function but has limitations in that there is no implementation guide and it is not extensible in its current form. HITSP took the HL7 Clinical Document Architecture (CDA) standard and began developing modules that could be selected to be combined to form a variety of summary documents. The relevant information can still be viewed at the HITSP website under C80 and especially C83. Keith Boone's blog is an excellent source for information on CDA and CCD.
Integrating the Healthcare Enterprise (IHE) has taken the lead to expand the list of defined summary documents. Under their system, these are called content profiles and are managed by the Patient Care Coordination (PCC) technical committees. Examples are emergency care summaries, antepartum records, immunization content summaries, and recently, nursing care summaries. I think that there is still an urgent need to develop hospital discharge summary and procedure summary specifications.
One of the advantages of these types of documents is that the standards already have been developed and tested. They can extend established workflows and offer a framework for exchanging structured data. With some work on data flow mapping vendors can use standards that provide solid interoperability. New document types can be developed simply by adding new modules, when needed. IHE, through the IHE Connectathon, and NIST through test specifications can provide the opportunities to test and validate the interoperability of the various health care documents and expand their capabilities as new document types are developed.
For those with further interest in learning about HL7 CDA and CCD there is a free webinar on September 14th. I recommend that you check it out.
The HIT Standards Committee had an interesting meeting in June. One of the discussions concerned documents. It seemed to me that some of the committee members did not understand current document standards, based on some of the comments. Some of the best sources for information on health documents can be found in previous work by HITSP, IHE, and the standards development organization, HL7.
In discussing document standards, one of the committee members was critical of documents because of the challenges of interoperability with potentially an infinite number of documents. Realistically, in medicine, only a few dozen document types need to be available and are used by clinicians on a regular basis.
In my opinion, the most important document type needed to immediately improve patient care in the US is the patient care summary. This type of document is useful whenever there is a transition of care, in inpatient and ambulatory environments. An example would be when a patient is transferred from one unit to another or from the hospital to a long term care setting. Outpatient use of patient care summaries is needed when a patient is referred to a specialist, sent for special diagnostic studies, and when the patient is sent back to their primary care clinician for continued care. The patient care summary is essential for patient engagement in their health care and personal health information management and may be useful to help update PHRs.
HL7 (CDA 2.0 R2) and HITSP (C32) have well accepted standards and implementation guides for this document type, the CCD. This standard is one of those specified recently in the final standards regulations. Its alternative, the CCR serves the same function but has limitations in that there is no implementation guide and it is not extensible in its current form. HITSP took the HL7 Clinical Document Architecture (CDA) standard and began developing modules that could be selected to be combined to form a variety of summary documents. The relevant information can still be viewed at the HITSP website under C80 and especially C83. Keith Boone's blog is an excellent source for information on CDA and CCD.
Integrating the Healthcare Enterprise (IHE) has taken the lead to expand the list of defined summary documents. Under their system, these are called content profiles and are managed by the Patient Care Coordination (PCC) technical committees. Examples are emergency care summaries, antepartum records, immunization content summaries, and recently, nursing care summaries. I think that there is still an urgent need to develop hospital discharge summary and procedure summary specifications.
One of the advantages of these types of documents is that the standards already have been developed and tested. They can extend established workflows and offer a framework for exchanging structured data. With some work on data flow mapping vendors can use standards that provide solid interoperability. New document types can be developed simply by adding new modules, when needed. IHE, through the IHE Connectathon, and NIST through test specifications can provide the opportunities to test and validate the interoperability of the various health care documents and expand their capabilities as new document types are developed.
For those with further interest in learning about HL7 CDA and CCD there is a free webinar on September 14th. I recommend that you check it out.
Sunday, July 25, 2010
Outlook for New Workforce Trainees
Dr. David Blumenthal announced last October that 50,000 new workers would be needed in the health information technology field. The Office of the National Coordinator established several grant programs designed to facilitate workforce training. Most of these training programs are due to kickoff this fall. So what is the job outlook for new trainees?
Interestingly, just last week, a report was released on previous federal jobs training programs. The results ranged from somewhat encouraging to downright discouraging. Time will tell how things will work out for the new HIT trainees. My advice to these students would be to take an approach of cautious optimism. For now, they should hold on to their day jobs (if they are employed.)
The programs are bound to be intensive. Until the national curricula are released, it would be too soon to judge if they cover subject matter in adequate depth to allow a graduate to function adequately in the real workplace. Most of the jobs I have seen posted on electronic bulletin boards require 5-7 years of experience in the field. Other barriers include a faltering economy that has impacted the health care field along with the rest of the economy. Cutbacks, hiring freezes, and even layoffs are occurring at hospitals and other health care organizations. Even employers with healthy balance sheets are taking a cautious approach towards hiring. Current employees are just being asked to be more productive.
There are potential employers on the horizon. This fall, many of the Regional Extension Centers will progress from the planning to the operations stage. Entry level jobs dealing with acquisition and implementation of ambulatory and inpatient EMRs should be created. Now that the final rules for certification, standards, and meaningful use have been published the way forward for the next two years is clearer. Clinicians and hospitals that have not already decided if they want to pursue the incentive funds that are available through Medicare and Medicaid programs will have to do so soon. Then the demand for new workforce trainees by the Regional Extension Centers, vendors, and consultants will be more accurately known.
Interestingly, just last week, a report was released on previous federal jobs training programs. The results ranged from somewhat encouraging to downright discouraging. Time will tell how things will work out for the new HIT trainees. My advice to these students would be to take an approach of cautious optimism. For now, they should hold on to their day jobs (if they are employed.)
The programs are bound to be intensive. Until the national curricula are released, it would be too soon to judge if they cover subject matter in adequate depth to allow a graduate to function adequately in the real workplace. Most of the jobs I have seen posted on electronic bulletin boards require 5-7 years of experience in the field. Other barriers include a faltering economy that has impacted the health care field along with the rest of the economy. Cutbacks, hiring freezes, and even layoffs are occurring at hospitals and other health care organizations. Even employers with healthy balance sheets are taking a cautious approach towards hiring. Current employees are just being asked to be more productive.
There are potential employers on the horizon. This fall, many of the Regional Extension Centers will progress from the planning to the operations stage. Entry level jobs dealing with acquisition and implementation of ambulatory and inpatient EMRs should be created. Now that the final rules for certification, standards, and meaningful use have been published the way forward for the next two years is clearer. Clinicians and hospitals that have not already decided if they want to pursue the incentive funds that are available through Medicare and Medicaid programs will have to do so soon. Then the demand for new workforce trainees by the Regional Extension Centers, vendors, and consultants will be more accurately known.
Tuesday, July 20, 2010
A Commercial Web-based HIE Offering from Verizonhttp://searchcloudcomputing.techtarget.com/news/article/0,289142,sid201_gci1516731,00.html
Last week, Verizon announced its entry into health information exchange. It has partnered with MedVirginia and Oracle to offer a backbone for HIE. The information provided in the press is a little hard to understand. It is not clear exactly what types of services will be offered. It seems like there will be the opportunity for each subscriber to participate in a master patient index. Also there will be user authentication and other privacy and security services. It is not clear if other services such as anonymization, data aggregation, and data processing for quality reporting will be available.
I have thought for a long time that the process of forming public health information exchanges is too complicated. Establishing governance structures, adopting standards, developing privacy and security protocols, debating consumer consent requirements are all time consuming. Often it is difficult to achieve stakeholder consensus concerning the issues. Furthermore, few of the existing HIEs have developed business plans that assure sustainability outside of federal or state grant processes. Even relatively simple approaches such as the NHIN Direct Project easily bog down.
Everyone involved in HIT realizes the importance of rapid deployment of HIE on a national basis. Meaningful use demands it. Yet results to date have been underwhelming. I think there are billions of dollars potentially at stake. It is not surprising then that a corporation with the resources of Verizon would develop a web-based approach that promises rapid implementation, scalability, and a sustainable business model. I predict that there will be many more efforts to provide HIT services using the Internet, cloud computing, and software as a service approaches. It should be interesting to see how the Verizon offering evolves.
I have thought for a long time that the process of forming public health information exchanges is too complicated. Establishing governance structures, adopting standards, developing privacy and security protocols, debating consumer consent requirements are all time consuming. Often it is difficult to achieve stakeholder consensus concerning the issues. Furthermore, few of the existing HIEs have developed business plans that assure sustainability outside of federal or state grant processes. Even relatively simple approaches such as the NHIN Direct Project easily bog down.
Everyone involved in HIT realizes the importance of rapid deployment of HIE on a national basis. Meaningful use demands it. Yet results to date have been underwhelming. I think there are billions of dollars potentially at stake. It is not surprising then that a corporation with the resources of Verizon would develop a web-based approach that promises rapid implementation, scalability, and a sustainable business model. I predict that there will be many more efforts to provide HIT services using the Internet, cloud computing, and software as a service approaches. It should be interesting to see how the Verizon offering evolves.
Friday, June 18, 2010
State Grants for Health Information Exchange
This week I was reading the monthly newsletter published by the Arizona Medical Association. This month's issue is devoted to health information technology projects being carried out in the state. I was particularly interested in the article written by Perry Yastrov concerning health information exchange in Arizona. Mr. Yastrov was the project director for Arizona Medical Information Exchange (AMIE), a proof of concept program to develop state-wide information exchange for the state Medicaid program. The project was funded by a federal Medicaid transformation grant. The three year effort came to an end late last year when funding ran out.
My understanding is that AMIE started from scratch. Policies and standards were agreed upon, procedures were developed, the technical infrastructure was built, a trust framework was adopted, and limited information exchange was piloted. Many stakeholders contributed to the effort. Several million patients were registered in the system. Now the participants don't have much to show for their work. The funding came from a federal grant program that did not include plans for sustainability. There have been numerous initiatives concerning health information exchange around the country that have met a similar fate. This leaves me wondering if we are spending our tax dollars wisely.
Earlier this year the Office of the National Coordinator for Health IT announced recipients of state grants to develop health information exchange (see State HIE grants.) Over $547 million in federal funding has been awarded to 56 entities to work on the same problem, state- or territory-wide health information exchange. To some extent, the awardees are expected to try to coordinate their efforts. The stated goal of this grants program is: "… building on existing efforts to advance regional and state-level health information exchange while moving toward nationwide interoperability." The outcome could be exactly the opposite.
One of the problems with health information exchange is that it does not scale well. A relatively simple approach can be taken to "pushing" data electronically from one provider to another. Tremendous complexity is required for fully enabled health information exchange that needs to occur seamlessly across various software platforms through jurisdictions that are governed by laws that often conflict. Just take a look at the particularly thorny issue of patient/consumer consent for an example of what I am talking about.
Since the days of the Constitutional Convention in the 1700's we have confronted the dilemma of how to balance federal influence and state's rights. That battle is still going on. I think the state HIE grants reflect the power and influence of state's rights advocates. Maybe this is a good way to distribute ARRA funds to stimulate the economic recovery. It may not be the best approach to stimulate the wide-spread development of interoperable HIEs needed for all stages of Meaningful Use. In my view, the federal government, as it spends money to promote health IT, should be taking a more aggressive role in harmonizing the various conflicting state laws and state initiatives to help us arrive at a place where health information exchange is facilitated, especially where information crosses jurisdictional boundaries. We should expand on best practices of the most successful HIEs, some of which have been working on the problem for over 20 years. Support infrastructure development and build out. We do not stand to gain much be reinventing the wheel 56 times. If we had had 50+ space programs, we would probably still be trying to land a person on the moon. Spend some of the money instead to discover truly sustainable solutions that can stand on their own without the continuous infusion of public funding and promote those to the state designated entities.
My understanding is that AMIE started from scratch. Policies and standards were agreed upon, procedures were developed, the technical infrastructure was built, a trust framework was adopted, and limited information exchange was piloted. Many stakeholders contributed to the effort. Several million patients were registered in the system. Now the participants don't have much to show for their work. The funding came from a federal grant program that did not include plans for sustainability. There have been numerous initiatives concerning health information exchange around the country that have met a similar fate. This leaves me wondering if we are spending our tax dollars wisely.
Earlier this year the Office of the National Coordinator for Health IT announced recipients of state grants to develop health information exchange (see State HIE grants.) Over $547 million in federal funding has been awarded to 56 entities to work on the same problem, state- or territory-wide health information exchange. To some extent, the awardees are expected to try to coordinate their efforts. The stated goal of this grants program is: "… building on existing efforts to advance regional and state-level health information exchange while moving toward nationwide interoperability." The outcome could be exactly the opposite.
One of the problems with health information exchange is that it does not scale well. A relatively simple approach can be taken to "pushing" data electronically from one provider to another. Tremendous complexity is required for fully enabled health information exchange that needs to occur seamlessly across various software platforms through jurisdictions that are governed by laws that often conflict. Just take a look at the particularly thorny issue of patient/consumer consent for an example of what I am talking about.
Since the days of the Constitutional Convention in the 1700's we have confronted the dilemma of how to balance federal influence and state's rights. That battle is still going on. I think the state HIE grants reflect the power and influence of state's rights advocates. Maybe this is a good way to distribute ARRA funds to stimulate the economic recovery. It may not be the best approach to stimulate the wide-spread development of interoperable HIEs needed for all stages of Meaningful Use. In my view, the federal government, as it spends money to promote health IT, should be taking a more aggressive role in harmonizing the various conflicting state laws and state initiatives to help us arrive at a place where health information exchange is facilitated, especially where information crosses jurisdictional boundaries. We should expand on best practices of the most successful HIEs, some of which have been working on the problem for over 20 years. Support infrastructure development and build out. We do not stand to gain much be reinventing the wheel 56 times. If we had had 50+ space programs, we would probably still be trying to land a person on the moon. Spend some of the money instead to discover truly sustainable solutions that can stand on their own without the continuous infusion of public funding and promote those to the state designated entities.
Wednesday, June 16, 2010
Messages vs. Documents
I have wanted to write about this topic for a while. Keep in mind that I am a clinician and not an engineer so what follows is my interpretation of how systems work.
The standards used to collect and manage the data most important to clinicians seem to come in two flavors, either messaging or documents. The newer standards and profiles that are being developed that deal with clinical workflow issues, clinical decision support, and reporting (quality and public health, for example) will not be the primary focus here. They are important to keep in mind however because of they will grow in significance over the next few years. The transition from Stage 1 through Stage 3 of Meaningful Use will drive future developments.
Documents have traditionally formed the bulk of the medical records clinicians keep on their patients. They provide a sense of permanence; they are not something to be used once and then discarded. Examples are history and physicals, discharge summaries, consultations, procedure reports, consents, and even laboratory reports. Documents, in the paper world, are so useful that their incorporation into electronic medical records should come as no surprise.
ASTM developed CCR, a sentinel standard for a clinical summary document. HL7, in an example of parallel innovation, developed CCD. Both are in common use today in EMRs. Superficially they seem very similar-section headers are similar and both are based on the XML programming language that offers the advantages of being both human readable and machine computable. At the core level though, they are different. CCR is strictly defined and modifications are therefore difficult. CCD, on the other hand is just one incidence of use of a standard developed by HL7, CDA or clinical document architecture. In simple terms, CDA is like an envelope and the letter it contains. On the outside there is certain routing information (like postage, address, and return address) and on the inside is the actual letter itself. There are potentially endless possibilities for CDA documents. HL7, IHE, and HITSP (when it still existed) have been leaders in development and amplification of this standard with implementation specifications/profiles. There are plans to develop a CDA template library/repository (see recent blog article by Keith Boone.) If vendors incorporate these templates into their systems, it will be a major step forward for interoperability. John Halamka recently wrote a blog article about how clinical summaries are used at his institution.
Vendors have voluntarily subjected their systems to interoperability testing at the annual IHE Connectathon, Many have then demonstrated their achievements at the HIMSS Interoperability Showcase that is featured at the HIMSS annual convention and trade show. One of the requirements for Stage 1 of Meaningful use is the ability of the EMR to create CCR or CCD documents. NIST (the National Institute for Standards and Technology) has developed tools that will be used to validate recognized CDA documents. These tools will be used by the yet to be determined certification agencies and testing labs during the required certification testing of EMRs.
Messaging standards are used for EMR tasks that tend to be more transient and process oriented. HL7 has developed complex standards for laboratory orders and lab results. X12 has developed standards to handle many of the administrative processes utilized in medical insurance related transactions such as eligibility checking, verification of insurance, claims processing, and prior authorization. There are a number of standards used to coordinate scheduling tasks.
I will reveal my bias and say that many of these purposes could be readily served by a document centric rather than a message-centered approach. For example, I would like to have a prior authorization document in my chart before I proceed with surgical care of a patient. Also, lab orders have traditionally been initiated by a document in the inpatient chart. Similarly, although lab results can be useful in message form, a lab result document is usually what clinicians use when they treat patients. HITSP recognized this dichotomy and worked last summer to harmonize standards for both lab result messages and lab result documents.
In the future, clinical decision support systems are likely to play an increasingly important role the EMR. Likewise, EMRs will be required to have the ability to collect and process data to provide a wide variety of quality reports and to forward data to public health entities. It would be idea if the clinical data to drive the necessary systems were collected at the point of care as a seamless function of providing care. Primarily, documents will be the source of the data that will facilitate this goal. The challenge will be to map the data elements so they can be easily accessed to be processed to complete the new tasks being developed.
The standards used to collect and manage the data most important to clinicians seem to come in two flavors, either messaging or documents. The newer standards and profiles that are being developed that deal with clinical workflow issues, clinical decision support, and reporting (quality and public health, for example) will not be the primary focus here. They are important to keep in mind however because of they will grow in significance over the next few years. The transition from Stage 1 through Stage 3 of Meaningful Use will drive future developments.
Documents have traditionally formed the bulk of the medical records clinicians keep on their patients. They provide a sense of permanence; they are not something to be used once and then discarded. Examples are history and physicals, discharge summaries, consultations, procedure reports, consents, and even laboratory reports. Documents, in the paper world, are so useful that their incorporation into electronic medical records should come as no surprise.
ASTM developed CCR, a sentinel standard for a clinical summary document. HL7, in an example of parallel innovation, developed CCD. Both are in common use today in EMRs. Superficially they seem very similar-section headers are similar and both are based on the XML programming language that offers the advantages of being both human readable and machine computable. At the core level though, they are different. CCR is strictly defined and modifications are therefore difficult. CCD, on the other hand is just one incidence of use of a standard developed by HL7, CDA or clinical document architecture. In simple terms, CDA is like an envelope and the letter it contains. On the outside there is certain routing information (like postage, address, and return address) and on the inside is the actual letter itself. There are potentially endless possibilities for CDA documents. HL7, IHE, and HITSP (when it still existed) have been leaders in development and amplification of this standard with implementation specifications/profiles. There are plans to develop a CDA template library/repository (see recent blog article by Keith Boone.) If vendors incorporate these templates into their systems, it will be a major step forward for interoperability. John Halamka recently wrote a blog article about how clinical summaries are used at his institution.
Vendors have voluntarily subjected their systems to interoperability testing at the annual IHE Connectathon, Many have then demonstrated their achievements at the HIMSS Interoperability Showcase that is featured at the HIMSS annual convention and trade show. One of the requirements for Stage 1 of Meaningful use is the ability of the EMR to create CCR or CCD documents. NIST (the National Institute for Standards and Technology) has developed tools that will be used to validate recognized CDA documents. These tools will be used by the yet to be determined certification agencies and testing labs during the required certification testing of EMRs.
Messaging standards are used for EMR tasks that tend to be more transient and process oriented. HL7 has developed complex standards for laboratory orders and lab results. X12 has developed standards to handle many of the administrative processes utilized in medical insurance related transactions such as eligibility checking, verification of insurance, claims processing, and prior authorization. There are a number of standards used to coordinate scheduling tasks.
I will reveal my bias and say that many of these purposes could be readily served by a document centric rather than a message-centered approach. For example, I would like to have a prior authorization document in my chart before I proceed with surgical care of a patient. Also, lab orders have traditionally been initiated by a document in the inpatient chart. Similarly, although lab results can be useful in message form, a lab result document is usually what clinicians use when they treat patients. HITSP recognized this dichotomy and worked last summer to harmonize standards for both lab result messages and lab result documents.
In the future, clinical decision support systems are likely to play an increasingly important role the EMR. Likewise, EMRs will be required to have the ability to collect and process data to provide a wide variety of quality reports and to forward data to public health entities. It would be idea if the clinical data to drive the necessary systems were collected at the point of care as a seamless function of providing care. Primarily, documents will be the source of the data that will facilitate this goal. The challenge will be to map the data elements so they can be easily accessed to be processed to complete the new tasks being developed.
Friday, May 28, 2010
Information Exchange Patterns
I haven't written for awhile. I started working part-time last month and I also went to two out-of-town meetings. I found that working part-time takes a lot of energy; much more than I expected. I have wanted to write about information exchange patterns. The problem I have found is that it is hard to understand the different patterns of information exchange. I have been listening in on a lot of HIT Policy Committee NHIN workgroup discussions. Nevertheless, my confusion has only grown. I will try to present an overview (according to my understanding) of the two basic types of health information exchange below.
I think the concepts of information exchange are easier understood at the high level than when you get into the details. In my mind, there are two characteristic types of information exchange-those that take place on a point-to-point basis and those that require networks with their associated intermediaries. Of course, this is over-simplified. Consider the point-to-point exchange we are all familiar with--email sent over the Internet. Even though I write a message and send it you, the email does not travel directly from my computer to yours. Rather, it is forwarded through a number of intermediate servers on the Internet backbone. My message could potentially be intercepted and even altered before you receive it. Obviously, this is not acceptable for the transmission of protected health information. The NHIN Direct Project is trying to solve problems with point-to-point information sharing for small medical practices.
Point-to-Point Sharing
The exchange pattern in this type of information comes in two flavors-send/receive and request/respond. Two examples should help clarify this exchange. A primary care physician is referring a patient to a specialist for a consultation. The primary care physician SENDS a CCD summary document to the specialist who RECEIVES the clinical summary. This information exchange is important for patient care because it is used to help facilitate a transfer of care. Studies have shown that traditional handoffs using paper records are high risk areas for important patient safety and quality information to be lost. This has been designated a priority area for meaningful use under ARRA. Some other examples of use cases for this type of exchange are: 1) a lab sends results to the ordering clinician, 2) a clinician sends an electronic prescription to a pharmacy, and 3) a hospital sends a patient discharge summary to the attending physician, and 4)a patient contacts their PCP with a question about their current medications.
Now suppose the specialist's staff check the next day's schedule and notice that the doctor is due to see a referral patient from a primary care clinician but they have not received any clinical information about the patient. They can REQUEST the information from the primary care clinician who hopefully then RESPONDS by sending a patient summary and a copy of the document explaining the reason for referral.
Basic requirements for these types of exchanges are a secure channel for message transmission because protected health information is to be transferred. The exchange is not secure if a traditional Internet connection is used (like http, for example.) But standards do exist that enable secure information exchange on the Internet through use of existing infrastructure. Greater security could be provided by encrypting the data in transit and/or using digital signatures to assure identities of the two parties and to make sure that the data is not altered in transit. The sending party has to "know" the address of the recipient and should verify that the information is being sent to the intended party. Many privacy advocates would inject consent issues into even this simple type of exchange. Current federal law-HIPAA-allows exchange without patient consent for treatment, payment, and health care operations purposes. Only the minimal necessary data should be sent. Complex governance structures and highly granular consent options are not usually envisioned for these types of information exchange, however. Point-to-point exchange is expected to meet many of the 2011 Stage 1 meaningful use requirements.
There are some problems with this type of exchange. Many small offices will not keep their systems available online 7/24/365. A longitudinal record
could not be exchanged easily using this method. Patient and provider directory services are not available.
Network-based Exchange
Network-based exchange usually occurs via a query/retrieve format. This is often a multistage transaction. The first, query, step might be- Do you have information on patient X? In the second step, the responder performs a registry search. Then the response might be- yes, we have CCD from dates a,b,c, lab results from dates a, d ,f, x-rays from dates g, h, i. The third step would be for the requestor to ask for the specific information (stored in one or many repositories.) The final step would be for the responder to retrieve the information and send it to the requestor.
The network-based exchanges may also support subscribe/publish services. This is similar to RSS feeds you are already familiar with. For example, a primary care physician may subscribe to a service that provides a notification any time new information for his/her patients x,y, and z is posted on the exchange. When patient x goes to the ED on Saturday night, information for that encounter would automatically be available in the doctor's office on Monday morning.
This type of exchange depends on a complex infrastructure of policies, services, and standards. There usually is a master patient index, registries, repositories, secure transport standards, authentication and authorization for exchange users, and a trust framework for how the data/information will be used, by whom, for what purposes. For example, participants in NHIN Exchange pilot projects have all agreed to use a DURSA- data use and reciprocal support agreement. Other services such as data aggregation, anonymization, and reporting functions might also be offered. Some form of networked health information will probably be needed to meet Stage 2 and 3 requirements for meaningful use. (The requirements have not yet been specified by ONC.)
John Moehrke has covered some of these issues in blog postings on Monday and Wednesday of this week. See his commentary.
I think the concepts of information exchange are easier understood at the high level than when you get into the details. In my mind, there are two characteristic types of information exchange-those that take place on a point-to-point basis and those that require networks with their associated intermediaries. Of course, this is over-simplified. Consider the point-to-point exchange we are all familiar with--email sent over the Internet. Even though I write a message and send it you, the email does not travel directly from my computer to yours. Rather, it is forwarded through a number of intermediate servers on the Internet backbone. My message could potentially be intercepted and even altered before you receive it. Obviously, this is not acceptable for the transmission of protected health information. The NHIN Direct Project is trying to solve problems with point-to-point information sharing for small medical practices.
Point-to-Point Sharing
The exchange pattern in this type of information comes in two flavors-send/receive and request/respond. Two examples should help clarify this exchange. A primary care physician is referring a patient to a specialist for a consultation. The primary care physician SENDS a CCD summary document to the specialist who RECEIVES the clinical summary. This information exchange is important for patient care because it is used to help facilitate a transfer of care. Studies have shown that traditional handoffs using paper records are high risk areas for important patient safety and quality information to be lost. This has been designated a priority area for meaningful use under ARRA. Some other examples of use cases for this type of exchange are: 1) a lab sends results to the ordering clinician, 2) a clinician sends an electronic prescription to a pharmacy, and 3) a hospital sends a patient discharge summary to the attending physician, and 4)a patient contacts their PCP with a question about their current medications.
Now suppose the specialist's staff check the next day's schedule and notice that the doctor is due to see a referral patient from a primary care clinician but they have not received any clinical information about the patient. They can REQUEST the information from the primary care clinician who hopefully then RESPONDS by sending a patient summary and a copy of the document explaining the reason for referral.
Basic requirements for these types of exchanges are a secure channel for message transmission because protected health information is to be transferred. The exchange is not secure if a traditional Internet connection is used (like http, for example.) But standards do exist that enable secure information exchange on the Internet through use of existing infrastructure. Greater security could be provided by encrypting the data in transit and/or using digital signatures to assure identities of the two parties and to make sure that the data is not altered in transit. The sending party has to "know" the address of the recipient and should verify that the information is being sent to the intended party. Many privacy advocates would inject consent issues into even this simple type of exchange. Current federal law-HIPAA-allows exchange without patient consent for treatment, payment, and health care operations purposes. Only the minimal necessary data should be sent. Complex governance structures and highly granular consent options are not usually envisioned for these types of information exchange, however. Point-to-point exchange is expected to meet many of the 2011 Stage 1 meaningful use requirements.
There are some problems with this type of exchange. Many small offices will not keep their systems available online 7/24/365. A longitudinal record
could not be exchanged easily using this method. Patient and provider directory services are not available.
Network-based Exchange
Network-based exchange usually occurs via a query/retrieve format. This is often a multistage transaction. The first, query, step might be- Do you have information on patient X? In the second step, the responder performs a registry search. Then the response might be- yes, we have CCD from dates a,b,c, lab results from dates a, d ,f, x-rays from dates g, h, i. The third step would be for the requestor to ask for the specific information (stored in one or many repositories.) The final step would be for the responder to retrieve the information and send it to the requestor.
The network-based exchanges may also support subscribe/publish services. This is similar to RSS feeds you are already familiar with. For example, a primary care physician may subscribe to a service that provides a notification any time new information for his/her patients x,y, and z is posted on the exchange. When patient x goes to the ED on Saturday night, information for that encounter would automatically be available in the doctor's office on Monday morning.
This type of exchange depends on a complex infrastructure of policies, services, and standards. There usually is a master patient index, registries, repositories, secure transport standards, authentication and authorization for exchange users, and a trust framework for how the data/information will be used, by whom, for what purposes. For example, participants in NHIN Exchange pilot projects have all agreed to use a DURSA- data use and reciprocal support agreement. Other services such as data aggregation, anonymization, and reporting functions might also be offered. Some form of networked health information will probably be needed to meet Stage 2 and 3 requirements for meaningful use. (The requirements have not yet been specified by ONC.)
John Moehrke has covered some of these issues in blog postings on Monday and Wednesday of this week. See his commentary.
Sunday, April 11, 2010
Clinician Workflow Revisited
I returned to part-time clinical practice as an orthopedic surgeon last week after a 2 year hiatus (retirement) to study medical informatics. I am now working in a hospital-based outpatient office practice. The system for clinical documentation is hybrid. Overall, I would say that the hospital rates a HIMSS analytics(sm) EMR Adoption Model Stage 1 or 2. Current notes are either dictated or handwritten. Prior clinic notes, labs, and inpatient hospital records are scanned into a program called Chartmax. Access is via a wired hospital network. To review x-rays, CT scans, MRIs and ultrasounds (via the hospital PACS system), a separate, dedicated computer and monitor are utilized for the best viewing resolution. In an orthopedic clinic we depend heavily on both systems. A separate username and password is needed to log on to a desktop computer with the PACS application and another set of usernames and passwords is needed to access the clinical application. The application for access to clinical information is set to automatically log out after 6 minutes of no activity. I must log on at least once (and often more than once) for every patient I see. Computers are located in a dedicated physician office located at the end of a hallway off the clinical exam rooms. A few hospital staff members may walk by but no patients access this area unsupervised. We have clinical staff outside the exam rooms, approximately midway down the hall virtually at all times.
Two years ago, for the computer system in my private office, I set up a local area network, an Internet-based practice management system, and access to hospital records via a physician portal that required 2-factor authentication. Computers were located 1) in my office just off the exam rooms, where I did all documentation, 2) at the front desk, and 3) in my assistant's office. It would be fair to say that all computers were located in "clinical areas" of the practice. For all practical purposes though, unsupervised patient access to the three desktops was extremely unlikely. No timeouts were set for automatic logoffs. I felt access to the electronic clinical systems was quite reasonable--secure logon with two factor authentication (I was the only one in the practice with a fob), immediate access to the systems when I sat down at my desk, and good security for electronic clinical information.
It is amazing to me how satisfied I was with the information systems as they worked in my office contrasted with how dissatisfied I am with the hospital's system that I am using now. Remember, I am a clinician who is an HIT advocate to the extent that I expended considerable energy and financial resources to obtain master's degree level training in the field. I would find it hard to promote the current hospital system to clinicians. I talked to a very high level manager of IT systems at the hospital about my concerns. He cited the hospital policy that requires applications in "clinical areas" to time out in 6 minutes. This is a rigid policy. There are no exceptions. I don't know who the people were that were involved in development of the hospital policy. It has the hallmarks of having had little clinician input. Policies such as these should only be established with extensive and broad-based clinician input, in my opinion. They should be reviewed frequently as the hospital information systems evolve. The number of logons I am required to perform definitely does not fit my clinical workflow, slows my work, decreases productivity, impairs work satisfaction, and does not add much, in this instance, to the security of the hospital's health information system.
Security and privacy of health information systems are top concerns of clinicians, health IT administrators, and the general public. Recent breach notification reporting requirements are putting increased pressures on IT staff to secure health systems. On the other hand, systems must be usable and meet workflow requirements if they are to engage clinician support. I don't think rigid, uninformed policies are the answer. NIST provided a useful framework for completing a risk assessment when making decisions about how to secure electronic systems. I recommend this highly accessible publication to followers of this blog.
Two years ago, for the computer system in my private office, I set up a local area network, an Internet-based practice management system, and access to hospital records via a physician portal that required 2-factor authentication. Computers were located 1) in my office just off the exam rooms, where I did all documentation, 2) at the front desk, and 3) in my assistant's office. It would be fair to say that all computers were located in "clinical areas" of the practice. For all practical purposes though, unsupervised patient access to the three desktops was extremely unlikely. No timeouts were set for automatic logoffs. I felt access to the electronic clinical systems was quite reasonable--secure logon with two factor authentication (I was the only one in the practice with a fob), immediate access to the systems when I sat down at my desk, and good security for electronic clinical information.
It is amazing to me how satisfied I was with the information systems as they worked in my office contrasted with how dissatisfied I am with the hospital's system that I am using now. Remember, I am a clinician who is an HIT advocate to the extent that I expended considerable energy and financial resources to obtain master's degree level training in the field. I would find it hard to promote the current hospital system to clinicians. I talked to a very high level manager of IT systems at the hospital about my concerns. He cited the hospital policy that requires applications in "clinical areas" to time out in 6 minutes. This is a rigid policy. There are no exceptions. I don't know who the people were that were involved in development of the hospital policy. It has the hallmarks of having had little clinician input. Policies such as these should only be established with extensive and broad-based clinician input, in my opinion. They should be reviewed frequently as the hospital information systems evolve. The number of logons I am required to perform definitely does not fit my clinical workflow, slows my work, decreases productivity, impairs work satisfaction, and does not add much, in this instance, to the security of the hospital's health information system.
Security and privacy of health information systems are top concerns of clinicians, health IT administrators, and the general public. Recent breach notification reporting requirements are putting increased pressures on IT staff to secure health systems. On the other hand, systems must be usable and meet workflow requirements if they are to engage clinician support. I don't think rigid, uninformed policies are the answer. NIST provided a useful framework for completing a risk assessment when making decisions about how to secure electronic systems. I recommend this highly accessible publication to followers of this blog.
Wednesday, March 31, 2010
Index through March 31, 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
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
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
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
Sunday, February 21, 2010
EHR Safety
Now is a good time to discuss EMR/EHR safety. The HIT Policy Committee Certification/Adoption Workgroup will be holding a public meeting on HIT Safety on February 25. An impressive group of experts has been assembled to present testimony on this important issue. Much of the literature on EHR safety to date suggests that electronic record systems are safer than a paper-based approach. Yet a few dissenting articles point to the potential for new types of errors and unintended consequences caused by EHRs. One article out of the University of Pennsylvania that stimulated a lot of conversation on the topic was published in JAMA in 2005. I will discuss some of the potential reasons that EHRs could cause errors below.
Software Design: This is probably the most apparent cause of errors. Many of us have had the experience of working with software that was released before all bugs were corrected. For many applications, this can be an annoyance, can delay work, and make us angry, but usually the result is not life-threatening. On the other hand, patient care software must be perfect out of the box. Even a single incidence of imperfect programming can be fatal. Software engineers for EHR applications have to be perfect.
Adults vs. Children. An area in health IT where system design is a recognized safety issue is pediatric care. This belies the truism that kids are not just small adults. Medication administration, blood product transfusion, and lab result interpretation are areas where the treatment of children and infants is different from that of adults. Medication doses are often quite different for pediatric patients compared to adults and need to be adjusted for body weight and organ function (dose adjusted based on lab results.) A criticism of many EHRs is that they don't account for these differences or at least make it difficult to address the pediatric requirements (drug alerts needs to be set up differently, a correct body weight must be available to the pharmacy system, the correct units of measure must be used.) Some pediatric hospitals have designed or contracted for pediatric-specific software.
Regression errors. We all know that EHR software is updated periodically (often an 18-24 month cycle.) When updates are installed, they are usually tested in a non-production environment to make sure they work as designed. Occasionally the updates can cause changes in function that result in errors that were not present in the earlier version of the software. This is more likely when disparate component systems are interfaced to create an enterprise EHR. Special attention must be given to such interfaces when upgrades in software are made. Regression testing to test for this type of error adds to the administrative overhead for system operators.
User Interface: I realize that the graphic user interface is really part of the system design but the emphasis here is on human factors engineering rather than computer science. Usability is the feature we are concerned with here. Consideration of human perception, workplace environment, and human-machine interactions are essential to the design of computer systems that will be used in the health care space. I addressed some common usability issues in a previous post (Nov. 22, 2009.) Critics of electronic medical record systems often cite poor usability as a factor that has contributed to the slow adoption of EHRs by clinicians. Representative examples are: some systems make it easy to click the wrong radio buttons; the need to scroll excessively; having to click through multiple pages to complete a task; inappropriate use of color; alert fatigue; and difficulty to easily undo unintended actions. A good case could also be made that inadequate attention paid to software usability explains some of the safety risks inherent in the use of EHRs. The aircraft/airline industry, on the other hand, has devoted extensive resources to human factors engineering in its successful effort to improve the safety of flight.
Standards: Standards are important to enable interoperability. Further, interoperability is necessary for the electronic transfer of patient specific health information from one provider to another. Information transfer is especially important to the safe care of patients during transitions of care. Many of the extant proprietary systems were not designed with information exchange in mind.
The ultimate goal is semantic interoperability-the ability to exchange information in a format that preserves its original meaning. This has been and will continue to be a problem in health IT. Often standards are written without published implementation guides to explain how to use them. Standards harmonization is not an easy task, is labor intensive, and it is often difficult to achieve solutions that are easy to implement.
Congress recognized the importance of the use of standards in health care IT in the composition of the ARRA legislation of 2009. The recent Interim Final Rule (IFR) on Certification and Standards is the most recent guide to the federal effort to influence standards in health IT. Whether the IFR fulfills the needs of the U.S. health care IT industry is a current topic of hot debate among the various stakeholders.
Clinical Decision Support: Decision support capabilities directly relate to patient safety. Alerts and warnings must be configured properly and implemented appropriately. Expert clinician input is essential. More complex decision support systems, especially those based on evidence-based guidelines are potentially problematic. The challenges become apparent when converting written guidelines to their electronic equivalents. Also, experience has shown that some clinical decision support systems may be sensitive to different geographic environments. Clinical outcomes when these systems are used are not totally predictable across different regions or cultures. Furthermore, many clinical decision support systems are necessarily customized to local policies, procedures, and clinical expertise of the clinicians so each implementation becomes unique.
Security, Privacy, and Infrastructure: These categories also have a significant impact on patient safety. A few examples will be discussed here.
First, let's start with patient identity. Positively identifying patients is essential to the provision of appropriate clinical care. Patient identification in the U.S. is hampered by lack of a nationwide patient identity system. This will become a more critical issue in the near future when cross-community exchange of patient information becomes a reality. Making sure the right records are associated with the right patients will become increasingly difficult as the number of patients included on master patient indices grows. Complicating this issue is the growing threat of medical identity theft.
Clinical IT systems, like other computer systems, are vulnerable to malware, malicious employees, and even cyber-terrorism. Risk assessment and risk mitigation will need to become more robust in the health care IT industry. Larger organizations with specialized IT teams are generally more capable of dealing with these threats than small clinician practices that function without such sophistication.
A final area that has not received adequate attention is data integrity. We need to be sure that data entered into systems is not inadvertently or intentionally changed inappropriately. More widespread use of technical safeguards to assure data integrity will be needed to protect critical clinical information systems. I expect that future iterations of the IFR will include requirements for digital signatures or similar technologies and non-repudiation of origin for producers of clinical data.
Above, I have discussed some topics that I think are important for the safe use of IT in health care environments. It will be interesting to listen to the testimony before the policy committee workgroup on Thursday to learn what their take is on EHR/EMR safety.
Software Design: This is probably the most apparent cause of errors. Many of us have had the experience of working with software that was released before all bugs were corrected. For many applications, this can be an annoyance, can delay work, and make us angry, but usually the result is not life-threatening. On the other hand, patient care software must be perfect out of the box. Even a single incidence of imperfect programming can be fatal. Software engineers for EHR applications have to be perfect.
Adults vs. Children. An area in health IT where system design is a recognized safety issue is pediatric care. This belies the truism that kids are not just small adults. Medication administration, blood product transfusion, and lab result interpretation are areas where the treatment of children and infants is different from that of adults. Medication doses are often quite different for pediatric patients compared to adults and need to be adjusted for body weight and organ function (dose adjusted based on lab results.) A criticism of many EHRs is that they don't account for these differences or at least make it difficult to address the pediatric requirements (drug alerts needs to be set up differently, a correct body weight must be available to the pharmacy system, the correct units of measure must be used.) Some pediatric hospitals have designed or contracted for pediatric-specific software.
Regression errors. We all know that EHR software is updated periodically (often an 18-24 month cycle.) When updates are installed, they are usually tested in a non-production environment to make sure they work as designed. Occasionally the updates can cause changes in function that result in errors that were not present in the earlier version of the software. This is more likely when disparate component systems are interfaced to create an enterprise EHR. Special attention must be given to such interfaces when upgrades in software are made. Regression testing to test for this type of error adds to the administrative overhead for system operators.
User Interface: I realize that the graphic user interface is really part of the system design but the emphasis here is on human factors engineering rather than computer science. Usability is the feature we are concerned with here. Consideration of human perception, workplace environment, and human-machine interactions are essential to the design of computer systems that will be used in the health care space. I addressed some common usability issues in a previous post (Nov. 22, 2009.) Critics of electronic medical record systems often cite poor usability as a factor that has contributed to the slow adoption of EHRs by clinicians. Representative examples are: some systems make it easy to click the wrong radio buttons; the need to scroll excessively; having to click through multiple pages to complete a task; inappropriate use of color; alert fatigue; and difficulty to easily undo unintended actions. A good case could also be made that inadequate attention paid to software usability explains some of the safety risks inherent in the use of EHRs. The aircraft/airline industry, on the other hand, has devoted extensive resources to human factors engineering in its successful effort to improve the safety of flight.
Standards: Standards are important to enable interoperability. Further, interoperability is necessary for the electronic transfer of patient specific health information from one provider to another. Information transfer is especially important to the safe care of patients during transitions of care. Many of the extant proprietary systems were not designed with information exchange in mind.
The ultimate goal is semantic interoperability-the ability to exchange information in a format that preserves its original meaning. This has been and will continue to be a problem in health IT. Often standards are written without published implementation guides to explain how to use them. Standards harmonization is not an easy task, is labor intensive, and it is often difficult to achieve solutions that are easy to implement.
Congress recognized the importance of the use of standards in health care IT in the composition of the ARRA legislation of 2009. The recent Interim Final Rule (IFR) on Certification and Standards is the most recent guide to the federal effort to influence standards in health IT. Whether the IFR fulfills the needs of the U.S. health care IT industry is a current topic of hot debate among the various stakeholders.
Clinical Decision Support: Decision support capabilities directly relate to patient safety. Alerts and warnings must be configured properly and implemented appropriately. Expert clinician input is essential. More complex decision support systems, especially those based on evidence-based guidelines are potentially problematic. The challenges become apparent when converting written guidelines to their electronic equivalents. Also, experience has shown that some clinical decision support systems may be sensitive to different geographic environments. Clinical outcomes when these systems are used are not totally predictable across different regions or cultures. Furthermore, many clinical decision support systems are necessarily customized to local policies, procedures, and clinical expertise of the clinicians so each implementation becomes unique.
Security, Privacy, and Infrastructure: These categories also have a significant impact on patient safety. A few examples will be discussed here.
First, let's start with patient identity. Positively identifying patients is essential to the provision of appropriate clinical care. Patient identification in the U.S. is hampered by lack of a nationwide patient identity system. This will become a more critical issue in the near future when cross-community exchange of patient information becomes a reality. Making sure the right records are associated with the right patients will become increasingly difficult as the number of patients included on master patient indices grows. Complicating this issue is the growing threat of medical identity theft.
Clinical IT systems, like other computer systems, are vulnerable to malware, malicious employees, and even cyber-terrorism. Risk assessment and risk mitigation will need to become more robust in the health care IT industry. Larger organizations with specialized IT teams are generally more capable of dealing with these threats than small clinician practices that function without such sophistication.
A final area that has not received adequate attention is data integrity. We need to be sure that data entered into systems is not inadvertently or intentionally changed inappropriately. More widespread use of technical safeguards to assure data integrity will be needed to protect critical clinical information systems. I expect that future iterations of the IFR will include requirements for digital signatures or similar technologies and non-repudiation of origin for producers of clinical data.
Above, I have discussed some topics that I think are important for the safe use of IT in health care environments. It will be interesting to listen to the testimony before the policy committee workgroup on Thursday to learn what their take is on EHR/EMR safety.
Tuesday, February 16, 2010
Some thoughts on the IFR and NPRM published in January by ONC
Now that I have time to review the NPRM for Meaningful Use and the IFR for Standards and Certifications, I have developed several personal comments that are listed below.
1. One of the objectives of the ARRA sections on health care was to encourage clinician adoption of electronic medical records. Congress decided not to provide up-front funds to assist clinicians purchase and install systems. Rather, a method was developed to provide rewards for adoption and meaningful use of systems once they are being used. In my opinion, this was a flawed approach. The cost just to purchase an EMR is $40,000-$50,000 per clinician. The costs for annual maintenance and upgrades are not included. Most small practices are not staffed to handle maintenance of the software and infrastructure needed for the critical availability service needed in medical practice. The level of funding set aside for even the earliest adopters is not as large an incentive as it might seem at first glance.
2. The requirements for meaningful use are also problematic at multiple levels. My opinion is that those most likely to meet the demands of meaningful use are the clinicians and hospitals that have already adopted EMRs/EHRs rather than new adopters. The amount of time it takes to make a system selection, develop an implementation plan, change processes, perform the actual installation, and complete training aligns poorly for new adopters with the tight time schedules required by ARRA to realize the maximal incentives. Even those who are already using electronic records are going to be challenged to make the changes to their systems that will assure compliance with meaningful use requirements and achieve maximum incentive payment.
The certification program requirements have not even been released yet although some hospitals would need to start meaningful use of certified systems in the U.S. fiscal year starting in October 2010, only eight months from now. The infrastructure for the new requirements for certification of systems does not exist. This is extremely worrisome considering that the whole foundation of meaningful use is based on the use of certified systems. I do not think that it will be easy to develop criteria for certification of modules and self-developed systems used at many sites that represent some of the currently most advanced users.
Meaningful use reporting requirements are bloated measures, many of which do not have current electronic versions. I have great difficulty finding value to patients or the general public engendered in many of the types of reports required. I think administrators have gone way overboard in developing this area of meaningful use. As a clinician, I would be interested in utilizing measures that actually resulted in improved health care outcomes. Over emphasis on process measures just adds to the ever-increasing administrative overhead clinicians face. I must ask, why would a clinician spend the large amount of money need to install an EMR and then not use it? Failure to use an installed system would assume that clinicians were not convinced of the benefits of EMRs, especially increased patient safety and improved quality of care. Most current systems are hard pressed to provide the numerators and denominators required even for the stage 1 reporting requirements. The challenge is even larger for clinicians who practice in a number of facilities that may use different systems. Furthermore, the infrastructure needed for electronic reporting for the most part does not exist. Moreover, CMS is not prepared to receive electronically many of the measures now being proposed. I think there will have to be a whole new department at the federal level just devoted to collecting reports and making sure each system is meeting all the requirements to qualify for federal incentive payments.
The plan for the three phase implementation of meaningful use requirements is another major barrier to EMR adoption. This effectively guarantees at least every two year upgrades in software, needs for new training, and perhaps needs for new hardware that will not be welcomed by clinicians struggling falling revenues, increasing costs, and nearly impossible demands on time available in their daily lives.
3. There have been many industry-wide comments on the lack of specificity of published selected standards. One area of hot contention is the requirement to be able to process both CCD and CCR documents. Others have commented extensively on lack of clarity regarding the important information transmission standards. Finally, there have been many comments indicating that the selected privacy and security standards do not meet the needs of the health care industry.
Final Thoughts
I would have hoped for a plan that would have been more effective at encouraging new adoptions of EMRs. I would have wished for a concentration on standards that encourage true interoperability, especially of summary information, for a start. My final wish would have been for a very substantial commitment to development of the infrastructure for health information exchange. The state grants for health information exchange announced last week by ONC are barely a start for this important new resource.
1. One of the objectives of the ARRA sections on health care was to encourage clinician adoption of electronic medical records. Congress decided not to provide up-front funds to assist clinicians purchase and install systems. Rather, a method was developed to provide rewards for adoption and meaningful use of systems once they are being used. In my opinion, this was a flawed approach. The cost just to purchase an EMR is $40,000-$50,000 per clinician. The costs for annual maintenance and upgrades are not included. Most small practices are not staffed to handle maintenance of the software and infrastructure needed for the critical availability service needed in medical practice. The level of funding set aside for even the earliest adopters is not as large an incentive as it might seem at first glance.
2. The requirements for meaningful use are also problematic at multiple levels. My opinion is that those most likely to meet the demands of meaningful use are the clinicians and hospitals that have already adopted EMRs/EHRs rather than new adopters. The amount of time it takes to make a system selection, develop an implementation plan, change processes, perform the actual installation, and complete training aligns poorly for new adopters with the tight time schedules required by ARRA to realize the maximal incentives. Even those who are already using electronic records are going to be challenged to make the changes to their systems that will assure compliance with meaningful use requirements and achieve maximum incentive payment.
The certification program requirements have not even been released yet although some hospitals would need to start meaningful use of certified systems in the U.S. fiscal year starting in October 2010, only eight months from now. The infrastructure for the new requirements for certification of systems does not exist. This is extremely worrisome considering that the whole foundation of meaningful use is based on the use of certified systems. I do not think that it will be easy to develop criteria for certification of modules and self-developed systems used at many sites that represent some of the currently most advanced users.
Meaningful use reporting requirements are bloated measures, many of which do not have current electronic versions. I have great difficulty finding value to patients or the general public engendered in many of the types of reports required. I think administrators have gone way overboard in developing this area of meaningful use. As a clinician, I would be interested in utilizing measures that actually resulted in improved health care outcomes. Over emphasis on process measures just adds to the ever-increasing administrative overhead clinicians face. I must ask, why would a clinician spend the large amount of money need to install an EMR and then not use it? Failure to use an installed system would assume that clinicians were not convinced of the benefits of EMRs, especially increased patient safety and improved quality of care. Most current systems are hard pressed to provide the numerators and denominators required even for the stage 1 reporting requirements. The challenge is even larger for clinicians who practice in a number of facilities that may use different systems. Furthermore, the infrastructure needed for electronic reporting for the most part does not exist. Moreover, CMS is not prepared to receive electronically many of the measures now being proposed. I think there will have to be a whole new department at the federal level just devoted to collecting reports and making sure each system is meeting all the requirements to qualify for federal incentive payments.
The plan for the three phase implementation of meaningful use requirements is another major barrier to EMR adoption. This effectively guarantees at least every two year upgrades in software, needs for new training, and perhaps needs for new hardware that will not be welcomed by clinicians struggling falling revenues, increasing costs, and nearly impossible demands on time available in their daily lives.
3. There have been many industry-wide comments on the lack of specificity of published selected standards. One area of hot contention is the requirement to be able to process both CCD and CCR documents. Others have commented extensively on lack of clarity regarding the important information transmission standards. Finally, there have been many comments indicating that the selected privacy and security standards do not meet the needs of the health care industry.
Final Thoughts
I would have hoped for a plan that would have been more effective at encouraging new adoptions of EMRs. I would have wished for a concentration on standards that encourage true interoperability, especially of summary information, for a start. My final wish would have been for a very substantial commitment to development of the infrastructure for health information exchange. The state grants for health information exchange announced last week by ONC are barely a start for this important new resource.
Saturday, January 9, 2010
Handheld Devices—The mobile clinician
The expansion in the use and utility of handheld devices is a trend that shows no sign of abating soon. What is relatively new over about the last 5 years is the convergence of light-weight computers and telecommunications devices. This has important implications for clinicians who may need to connect to EHR systems anytime, anywhere to optimize the care they provide their patients. Wireless technology offers the possibility of remote access from almost any location in the country or world. There are still some significant issues for broadband access in some areas in the U.S., usually rural, where broadband infrastructure is not yet developed or excessively costly.
Increased adoption of EMR/EHR technology by clinicians in ambulatory and hospital settings will spur the decision to use hard-wired or wireless devices to access clinical systems. Hard-wired approaches may be faster and more secure but usually require a fixed base of operations. Wireless devices, on the other hand, are often carried from room to room or site to site. Currently the most popular hardware choices for those using wireless connections are laptops and tablet style designs. The capabilities of handheld devices, such as smart phones, have advanced rapidly and are supplanting other types of hardware in a number of situations.
Those who round on patients in the hospital need to access the hospital information system to write orders and clinical notes and to check labs, x-rays, and other results. Administrative functions also need to be accessed to bill for professional services and perhaps to check formularies and eligibility. The clinician may have the option of using the hospital network infrastructure or public telecommunications to connect. Outside the hospital, clinicians need to communicate with nursing staff, check results, submit orders, and prescribe medicines. They may also want to communicate with patients and other clinicians via (secure) email. Interestingly, from a security standpoint, cell phones offer the possibility of providing two factor authentification.
A wide range of developers are working to make necessary functions available in small handheld devices. Some are clinicians with programming interest and expertise. Others are large, well-established vendors. The race is certainly on to provide the richest capabilities in the smallest devices. The desire to provide full functionality for effective use during clinical activities in a phone-like device presents a true challenge. This is especially true when one considers the limitations imposed by small screen size, requirements to provide access to a variety of applications, and the need for good readability in a wide variety of working and lighting conditions.
Increased adoption of EMR/EHR technology by clinicians in ambulatory and hospital settings will spur the decision to use hard-wired or wireless devices to access clinical systems. Hard-wired approaches may be faster and more secure but usually require a fixed base of operations. Wireless devices, on the other hand, are often carried from room to room or site to site. Currently the most popular hardware choices for those using wireless connections are laptops and tablet style designs. The capabilities of handheld devices, such as smart phones, have advanced rapidly and are supplanting other types of hardware in a number of situations.
Those who round on patients in the hospital need to access the hospital information system to write orders and clinical notes and to check labs, x-rays, and other results. Administrative functions also need to be accessed to bill for professional services and perhaps to check formularies and eligibility. The clinician may have the option of using the hospital network infrastructure or public telecommunications to connect. Outside the hospital, clinicians need to communicate with nursing staff, check results, submit orders, and prescribe medicines. They may also want to communicate with patients and other clinicians via (secure) email. Interestingly, from a security standpoint, cell phones offer the possibility of providing two factor authentification.
A wide range of developers are working to make necessary functions available in small handheld devices. Some are clinicians with programming interest and expertise. Others are large, well-established vendors. The race is certainly on to provide the richest capabilities in the smallest devices. The desire to provide full functionality for effective use during clinical activities in a phone-like device presents a true challenge. This is especially true when one considers the limitations imposed by small screen size, requirements to provide access to a variety of applications, and the need for good readability in a wide variety of working and lighting conditions.
Subscribe to:
Posts (Atom)
Posts
