A Commercial Web-based HIE Offering from Verizon July 20, 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
Clinical Decision Support Systems Mar. 23, 2011
Clinician Workflow April 11, 2010
Consumer Preferences Nov. 2, 2009
Dr. Blumenthal--An Inspirational Keynote Address at HIMSS10 Mar. 7, 2010
EHR's for Surgeons/specialists Nov. 19, 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 Ontologies of the Future Jan. 12, 2011
Health IT Workforce Training Dec. 27, 2009
HIMSS 11 ARRA Usability Symposium Mar. 2, 2011
HIT Workforce Training Dec. 14, 2009
Imaging and Meaningful Use Debate Jan. 27, 2011
Information Exchange Patterns May 28, 2010
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
Messages vs. Documents June 16, 2010
More Thoughts on Documents Sept. 6, 2010
My Favorite Day at HIMSS 11 Mar. 3, 2011
NA Connectathon 2011 Jan. 22, 2011
Online Education Sept.10, 2009
Online Graduate Degrees-My Experience Nov. 18, 2009
Optionality and Interoperability in Health Care Software Dec. 6, 2010
Outlook for New Workforce Trainees July 25, 2010
Patient Portals Mar. 30, 2011
PCAST Report Thoughts Feb. 11, 2011
Planning for HIMSS11 Dec. 1, 2010
Provider Directories Mar. 31, 2011
Quality Reporting Sept. 30, 2009
Reconciliation-an unmet Challenge Sept. 14, 2009
State Grants for Health Information Exchange June 18, 2010
Summary of the HIT Policy Committee Workgroup hearing Mar. 15, 2010
on EHR Safety
The Direct Project Goes Live Mar. 1, 2011
Thought on the NHIN Mar. 18, 2010
Thursday, March 31, 2011
Provider Directories
Interest in provider directories has increased as efforts to promote health information exchange have spread across the country. Federal policy, through ARRA, has also provided a strong impetus. Directories offer access to the information users need to contact partners for the exchange of health information. The federal advisory committees, both the Health Information Technology Policy Committee (HITPC) and the Health Information Technology Standards Committee (HITSC), have established work groups to help develop policy and select standards that deal with directories. Two flavors of directories have been envisioned by these work groups. Entity Level Provider Directories (ELPDs) could be thought of as listing mostly large enterprises with more than one provider such as hospitals, group practices, payors, etc. The entity would be responsible for routing information and protecting privacy and security of information within its walls. On the other hand, Individual Level Provider Directories (ILPDs) would provide information about individual providers. What are the purposes of directories?
Directories function like electronic white/yellow pages. The information they contain might include basic demographics (names, addresses, phone numbers etc.), electronic addressing information (URLs) of the anticipated recipient, and digital certificates or links to certificates (certificates fulfill a number of very important privacy and security roles-they are used for authentication, digital signatures, and are the keys used to encrypt and decrypt protected health information), and information about types of information exchange applications supported. Some directories deliver the entire directory on user request. Others utilize a query function so that users can select filters to locate the specific information they are seeking. How are directories established?
There are a number of approaches being used to set up directories. First the sources of data must be identified. Software and hardware configurations must be determined. An entity must be selected that will take the responsibility of hosting the directory. Directory information must be maintained so that the information is accurate and up-to-date. Those with experience managing directories have found this to be a real challenge. The business model chosen for the directory should provide guidance for financing the establishment and on-going operating expenses. Directories are easier to manage when they serve a limited geographic or functional area. Nationwide information exchange would most likely depend on a federated model of interoperable directories. The actual architecture at this level can become complex. Some of the standards used in directories, such as Lightweight Directory Access Protocol (LDAP) are mature and well established. Others are still being developed and tested. Many of the currently functioning directories were home-grown and employ proprietary software. For more information concerning directories look at the first part of the meeting slide deck of the HITSC Privacy and Security WG meeting of March 24th.
A reasonable question is: why do we need directories at all? It is possible search for providers using the Internet or we can dial information on the telephone. Once we have a telephone number, then the other contact information may be just a call away. I think the answer is that directories can facilitate these manual processes and help make them more efficient. Of course, once contact information is located it can be stored on one's own system, much like we store contact information for email systems.
There are problems related to directories. They do not scale easily, as mentioned previously. Another problem is that many clinicians work at a number of institutions or provide care and use EHRs at multiple sites. Trying to determine which of all the possible contact addresses would be the correct one for the purpose intended will require an exercise in logic and some luck. Furthermore, having two different types of directories may create a level of complexity that may be difficult for all but the most tech savvy users to navigate. Directories may present more complexity than is necessary. For example, the contact information needed to use the Nw-HIN Direct specification requires just two pieces of information: a URL for the recipient and the associated digital certificate. These can be transferred using old-fashioned email.
The HITPC and HITSC will be completing their discussion on the two types of provider directories over the next few months. Then they will make recommendations to the Office of the National Coordinator for Meaningful Use stages 2 and 3. It will be an interesting process to keep an eye on.
Directories function like electronic white/yellow pages. The information they contain might include basic demographics (names, addresses, phone numbers etc.), electronic addressing information (URLs) of the anticipated recipient, and digital certificates or links to certificates (certificates fulfill a number of very important privacy and security roles-they are used for authentication, digital signatures, and are the keys used to encrypt and decrypt protected health information), and information about types of information exchange applications supported. Some directories deliver the entire directory on user request. Others utilize a query function so that users can select filters to locate the specific information they are seeking. How are directories established?
There are a number of approaches being used to set up directories. First the sources of data must be identified. Software and hardware configurations must be determined. An entity must be selected that will take the responsibility of hosting the directory. Directory information must be maintained so that the information is accurate and up-to-date. Those with experience managing directories have found this to be a real challenge. The business model chosen for the directory should provide guidance for financing the establishment and on-going operating expenses. Directories are easier to manage when they serve a limited geographic or functional area. Nationwide information exchange would most likely depend on a federated model of interoperable directories. The actual architecture at this level can become complex. Some of the standards used in directories, such as Lightweight Directory Access Protocol (LDAP) are mature and well established. Others are still being developed and tested. Many of the currently functioning directories were home-grown and employ proprietary software. For more information concerning directories look at the first part of the meeting slide deck of the HITSC Privacy and Security WG meeting of March 24th.
A reasonable question is: why do we need directories at all? It is possible search for providers using the Internet or we can dial information on the telephone. Once we have a telephone number, then the other contact information may be just a call away. I think the answer is that directories can facilitate these manual processes and help make them more efficient. Of course, once contact information is located it can be stored on one's own system, much like we store contact information for email systems.
There are problems related to directories. They do not scale easily, as mentioned previously. Another problem is that many clinicians work at a number of institutions or provide care and use EHRs at multiple sites. Trying to determine which of all the possible contact addresses would be the correct one for the purpose intended will require an exercise in logic and some luck. Furthermore, having two different types of directories may create a level of complexity that may be difficult for all but the most tech savvy users to navigate. Directories may present more complexity than is necessary. For example, the contact information needed to use the Nw-HIN Direct specification requires just two pieces of information: a URL for the recipient and the associated digital certificate. These can be transferred using old-fashioned email.
The HITPC and HITSC will be completing their discussion on the two types of provider directories over the next few months. Then they will make recommendations to the Office of the National Coordinator for Meaningful Use stages 2 and 3. It will be an interesting process to keep an eye on.
Wednesday, March 30, 2011
Patient Portals
Patient Portals
A Federal priority for health information technology in the U.S. is patient engagement. The aim is to involve patients more directly in their medical care, especially for those with chronic diseases, to improve outcomes and reduce costs. One of the key principles is to provide information to patients in a more transparent, easy to use format so that information can be used for improved medical management and to support behavior modification when it is needed. Patient portals offer EHR owners a method to meet some of the Meaningful Use stage 1 requirements. Portals vary in functionality so one-size-fits-all certainly does not apply.
One of the primary functions of a patient portal is to provide access to a patient's medical record. This can open up the entire chart, certain predetermined sections, or a summary document such as a CCD or CCR. Options include the ability only to view data or the possibility of uploading information to a home device or personal health record. Some portals allow patients to make contributions to the record such as correction of errors, annotations and other patient-generated types of data. Other functions have also been enabled by some portal designers. Popular features include the ability of patients to request medication refills online, patient mediated appointment scheduling, and secure email interchange with a clinician or office staff. Other portals offer bill payment options, ways to complete medical history questionnaires, patient education materials, and even social media site links.
One idea is to give patients more control over their medical information. As many know, consent for release of information has been a challenging policy and technical barrier to more robust information exchange. There are those who think that the patient should be solely in control of information flow by uploading all their health information to a personal health record. Then the patient could decide to whom to release information, which information, for what purposes of use, and for how long. This clearly represents an optimistic view of the health care community's ability to engage patients. Experience to date with large patient portal implementations has shown that only a minority of patients make use portals. Consumer adoption of PHRs has likewise been disappointing.
The Direct Project specification, as it is rolled out and implemented by major EHR vendors, may be a game-changer for both use of portals and adoption of PHRs. Direct should make it easier to direct the push of information from EHRs to PHRs so that the workflow becomes more automated and "easy" to perform.
There have been some concerns about privacy issues. Patients accessing portals often are authenticated by a single factor through use of user names and passwords. This is a relatively weak method for user identification. Furthermore, EHR owners are concerned that use of patient portals could expose them to data breaches and malicious attacks. These issues will have to be addressed through policy and technology development as we move through the more advanced stages of Meaningful Use.
A Federal priority for health information technology in the U.S. is patient engagement. The aim is to involve patients more directly in their medical care, especially for those with chronic diseases, to improve outcomes and reduce costs. One of the key principles is to provide information to patients in a more transparent, easy to use format so that information can be used for improved medical management and to support behavior modification when it is needed. Patient portals offer EHR owners a method to meet some of the Meaningful Use stage 1 requirements. Portals vary in functionality so one-size-fits-all certainly does not apply.
One of the primary functions of a patient portal is to provide access to a patient's medical record. This can open up the entire chart, certain predetermined sections, or a summary document such as a CCD or CCR. Options include the ability only to view data or the possibility of uploading information to a home device or personal health record. Some portals allow patients to make contributions to the record such as correction of errors, annotations and other patient-generated types of data. Other functions have also been enabled by some portal designers. Popular features include the ability of patients to request medication refills online, patient mediated appointment scheduling, and secure email interchange with a clinician or office staff. Other portals offer bill payment options, ways to complete medical history questionnaires, patient education materials, and even social media site links.
One idea is to give patients more control over their medical information. As many know, consent for release of information has been a challenging policy and technical barrier to more robust information exchange. There are those who think that the patient should be solely in control of information flow by uploading all their health information to a personal health record. Then the patient could decide to whom to release information, which information, for what purposes of use, and for how long. This clearly represents an optimistic view of the health care community's ability to engage patients. Experience to date with large patient portal implementations has shown that only a minority of patients make use portals. Consumer adoption of PHRs has likewise been disappointing.
The Direct Project specification, as it is rolled out and implemented by major EHR vendors, may be a game-changer for both use of portals and adoption of PHRs. Direct should make it easier to direct the push of information from EHRs to PHRs so that the workflow becomes more automated and "easy" to perform.
There have been some concerns about privacy issues. Patients accessing portals often are authenticated by a single factor through use of user names and passwords. This is a relatively weak method for user identification. Furthermore, EHR owners are concerned that use of patient portals could expose them to data breaches and malicious attacks. These issues will have to be addressed through policy and technology development as we move through the more advanced stages of Meaningful Use.
Wednesday, March 23, 2011
Clinical Decision Support Systems
Clinical Decision Support
Clinical decision support (CDS) is going to be an important element of Meaningful Use Stages 2 and 3. Decision support functions will go far beyond those of drug allergy alerts and drug interaction checking that are necessary in Stage 1. In this post I will discuss diagnostic CDS. Wikipedia has an excellent general introductory discussion of CDS. You might also want to check the links to Isabel and SimulConsult. These are two examples of diagnostic CDS systems that are already commercially available. The former uses subject matter experts to generate content and the latter utilizes a computational wiki.
There have been several times in my career where diagnostic CDS would have been helpful. First, one must understand how doctors establish diagnoses. Usually this is done via a series of heuristics, rules of thumb, that often work very efficiently for the diagnosis of common conditions. The problem with heuristics is that there are a number of biases that can lead one in the wrong direction and thus to the wrong diagnosis. If the diagnosis for a patient is not correct, then the treatment instituted is likely to be incorrect. Let me provide a few examples from my clinical experience.
Years ago, I evaluated a patient in the ortho clinic with wrist pain. His usual clinician was away so I was seeing the patient. He had been treated for several months with non-steroidal anti-inflammatories with minimal relief of symptoms. Overuse syndromes, minor sprains, and arthritis are common causes of joint pain so the working diagnosis was one of these. I reviewed his previous x-rays and was struck by the marked washing out of mineral (a finding known as osteopenia) from all the wrist bones. I recalled that among the possible etiologies of this x-ray finding is tuberculosis. It also turned out that the patient had a racial background that showed a susceptibility to tuberculosis infection. I performed a synovial biopsy of the wrist that came back positive for TB at 4 weeks. The treatment was changed from NSAIDs to triple anti-tuberculous antibiotic therapy. The initial treating physician thought the problem a common one. Here availability bias resulted in a diagnostic error. Now I would like to relate another example.
I was called to the operating room to see a patient with an infected foot. The treating surgeon was a very good orthopedists. He was taking a reasonable approach by treating the presumed infection/ulcer with surgery and antibiotics. The patient had what appeared to be a large ulcer with pus at his heel/instep area. Initially, there did not appear to be a good reason for this patient to have a spontaneous foot infection. As a consultant, I carefully reviewed the chart. Two data elements that initially were not given proper weight led me to the correct diagnosis. The patient had a history of inflammatory bowel disease. In fact, he had a small fistula from bowel to his anterior abdominal wall (this is characteristic of regional enteritis, one of the inflammatory bowel diseases.) Also, the very compulsive ward nurses took a photograph of the initial appearance of the foot. That photo showed a bullous lesion (a clear blister) rather than a pustule (abscess.) Only a few conditions cause bullae. Since I had an interest in dermatology as a medical student I knew where to look for the diagnostic label. Pyoderma gangranosum is a skin condition associated with inflammatory bowel disease that starts as a bullous lesion. The diagnosis is made by clinical history, appearance of the lesion, and microscopy of a biopsy of the lesion. The treatment, surprisingly, is high dose intravenous steroids, something we would never consider in the treatment of infections because steroids inhibit the body’s immune defenses. The healing process was slow once the treatment was changed but the patient did not require further surgery. The heuristic bias here was representativeness.
It is possible that both of these incorrect diagnoses could have been avoided if the treating physicians had had EHRs with diagnostic CDS running in the background. Then the diagnosis in the first case would have keyed on the differential of diffuse periarticular osteopenia- either the radiologist or the orthopedist would have needed to enter the proper term in the record. In the second case, an entry of a bullous skin lesion on the physical exam or a skin biopsy narrative would have been needed to feed the CDS system with the necessary data to help with the correct diagnosis. This emphasizes the point that use of CDS is not cookbook medicine. To have good CDS you have to have expert clinicians who can provide the terms from history, physical exam, laboratory and x-ray studies that when coded properly will allow the CDS system to do its job. Otherwise we have the problem of garbage-in, garbage-out. A recent post on John Moehrke's blog discusses some of the data gathering issues with CDS systems as well as some relevant privacy concerns.
One of the problem with heuristics is that the probabilities are not really what the clinician thinks. Bayes' theorem is a mathematical formula that addresses probability of diagnoses before and after tests. This is familiar to many who work in the CDS field but not often considered or used by others. Clinicians are generally not well trained in probability theory as it relates to diagnosis and interpretation of tests. Other important statistical terms that should be considered in clinical diagnosis are sensitivity, specificity, positive predictive value, negative predictive value, and the accuracy of given tests. One also needs to know which of these statistical measures regarding tests are most important to weigh when “ruling in” a condition or in “ruling out” a condition. This tragically hit too close to home recently when my brother-in-law died suddenly from a pulmonary embolism.
Early one week he had sudden onset of sharp right-sided chest/abdominal/flank pain. He was seen by a physician's assistant at an urgent care center. He was discharged with a recommendation to obtain an abdominal ultrasound on an elective basis. Several days later he got on an airplane and traveled from the west coast to the midwest. The evening of arrival he experienced severe right sided flank pain, shortness of breath, low grade fever, low blood oxygen content, and hemoptysis. The differential included pneumonia and pulmonary embolism. The history, physical, and lab tests should have led to the conclusion based on probabilities that pulmonary embolism was just as likely as pneumonia. When a CT angiogram of the chest did not show evidence of an embolism then the clinicians wrongly concluded that he had pneumonia. The bias here was anchoring. Treatment was with antibiotics and pulmonary support. Further studies should have been done that most likely would have revealed the correct diagnosis. Several days after discharge from the hospital and another cross-country airplane trip, my brother-in-law collapsed at home and was dead 2 hours later. Postmortem showed no signs of pneumonia but rather acute and subacute pulmonary embolism. This devastated my family. I cannot help but wonder if a good CDS system had been used that the clinicians would have been reminded to do the correct tests and then institute the correct treatment with anticoagulants (blood thinners) rather than antibiotics. This is exactly what diagnostic CDS is all about. It would have saved his life.
Clinical decision support (CDS) is going to be an important element of Meaningful Use Stages 2 and 3. Decision support functions will go far beyond those of drug allergy alerts and drug interaction checking that are necessary in Stage 1. In this post I will discuss diagnostic CDS. Wikipedia has an excellent general introductory discussion of CDS. You might also want to check the links to Isabel and SimulConsult. These are two examples of diagnostic CDS systems that are already commercially available. The former uses subject matter experts to generate content and the latter utilizes a computational wiki.
There have been several times in my career where diagnostic CDS would have been helpful. First, one must understand how doctors establish diagnoses. Usually this is done via a series of heuristics, rules of thumb, that often work very efficiently for the diagnosis of common conditions. The problem with heuristics is that there are a number of biases that can lead one in the wrong direction and thus to the wrong diagnosis. If the diagnosis for a patient is not correct, then the treatment instituted is likely to be incorrect. Let me provide a few examples from my clinical experience.
Years ago, I evaluated a patient in the ortho clinic with wrist pain. His usual clinician was away so I was seeing the patient. He had been treated for several months with non-steroidal anti-inflammatories with minimal relief of symptoms. Overuse syndromes, minor sprains, and arthritis are common causes of joint pain so the working diagnosis was one of these. I reviewed his previous x-rays and was struck by the marked washing out of mineral (a finding known as osteopenia) from all the wrist bones. I recalled that among the possible etiologies of this x-ray finding is tuberculosis. It also turned out that the patient had a racial background that showed a susceptibility to tuberculosis infection. I performed a synovial biopsy of the wrist that came back positive for TB at 4 weeks. The treatment was changed from NSAIDs to triple anti-tuberculous antibiotic therapy. The initial treating physician thought the problem a common one. Here availability bias resulted in a diagnostic error. Now I would like to relate another example.
I was called to the operating room to see a patient with an infected foot. The treating surgeon was a very good orthopedists. He was taking a reasonable approach by treating the presumed infection/ulcer with surgery and antibiotics. The patient had what appeared to be a large ulcer with pus at his heel/instep area. Initially, there did not appear to be a good reason for this patient to have a spontaneous foot infection. As a consultant, I carefully reviewed the chart. Two data elements that initially were not given proper weight led me to the correct diagnosis. The patient had a history of inflammatory bowel disease. In fact, he had a small fistula from bowel to his anterior abdominal wall (this is characteristic of regional enteritis, one of the inflammatory bowel diseases.) Also, the very compulsive ward nurses took a photograph of the initial appearance of the foot. That photo showed a bullous lesion (a clear blister) rather than a pustule (abscess.) Only a few conditions cause bullae. Since I had an interest in dermatology as a medical student I knew where to look for the diagnostic label. Pyoderma gangranosum is a skin condition associated with inflammatory bowel disease that starts as a bullous lesion. The diagnosis is made by clinical history, appearance of the lesion, and microscopy of a biopsy of the lesion. The treatment, surprisingly, is high dose intravenous steroids, something we would never consider in the treatment of infections because steroids inhibit the body’s immune defenses. The healing process was slow once the treatment was changed but the patient did not require further surgery. The heuristic bias here was representativeness.
It is possible that both of these incorrect diagnoses could have been avoided if the treating physicians had had EHRs with diagnostic CDS running in the background. Then the diagnosis in the first case would have keyed on the differential of diffuse periarticular osteopenia- either the radiologist or the orthopedist would have needed to enter the proper term in the record. In the second case, an entry of a bullous skin lesion on the physical exam or a skin biopsy narrative would have been needed to feed the CDS system with the necessary data to help with the correct diagnosis. This emphasizes the point that use of CDS is not cookbook medicine. To have good CDS you have to have expert clinicians who can provide the terms from history, physical exam, laboratory and x-ray studies that when coded properly will allow the CDS system to do its job. Otherwise we have the problem of garbage-in, garbage-out. A recent post on John Moehrke's blog discusses some of the data gathering issues with CDS systems as well as some relevant privacy concerns.
One of the problem with heuristics is that the probabilities are not really what the clinician thinks. Bayes' theorem is a mathematical formula that addresses probability of diagnoses before and after tests. This is familiar to many who work in the CDS field but not often considered or used by others. Clinicians are generally not well trained in probability theory as it relates to diagnosis and interpretation of tests. Other important statistical terms that should be considered in clinical diagnosis are sensitivity, specificity, positive predictive value, negative predictive value, and the accuracy of given tests. One also needs to know which of these statistical measures regarding tests are most important to weigh when “ruling in” a condition or in “ruling out” a condition. This tragically hit too close to home recently when my brother-in-law died suddenly from a pulmonary embolism.
Early one week he had sudden onset of sharp right-sided chest/abdominal/flank pain. He was seen by a physician's assistant at an urgent care center. He was discharged with a recommendation to obtain an abdominal ultrasound on an elective basis. Several days later he got on an airplane and traveled from the west coast to the midwest. The evening of arrival he experienced severe right sided flank pain, shortness of breath, low grade fever, low blood oxygen content, and hemoptysis. The differential included pneumonia and pulmonary embolism. The history, physical, and lab tests should have led to the conclusion based on probabilities that pulmonary embolism was just as likely as pneumonia. When a CT angiogram of the chest did not show evidence of an embolism then the clinicians wrongly concluded that he had pneumonia. The bias here was anchoring. Treatment was with antibiotics and pulmonary support. Further studies should have been done that most likely would have revealed the correct diagnosis. Several days after discharge from the hospital and another cross-country airplane trip, my brother-in-law collapsed at home and was dead 2 hours later. Postmortem showed no signs of pneumonia but rather acute and subacute pulmonary embolism. This devastated my family. I cannot help but wonder if a good CDS system had been used that the clinicians would have been reminded to do the correct tests and then institute the correct treatment with anticoagulants (blood thinners) rather than antibiotics. This is exactly what diagnostic CDS is all about. It would have saved his life.
Thursday, March 3, 2011
My Favorite Day at HIMSS11
Tuesday, February 22 was my favorite day at HIMSS11. I watched a scenario that demonstrated the future of health information exchange at the Interoperability Showcase-but it was live and happening today. This year the Showcase featured the introduction of a third theater, Theater C, purposed for live demonstrations and special lectures for a large audience. Previously, the only option to see interoperability in action was to take one of the docent-led tours at the Showcase. Tours with a small group of attendees moved from one vendor table to another in a series of steps orchestrated to demonstrate a particular exchange scenario. Theater C brought the vendors to the audience instead. This innovation was wildly popular with Interoperability Showcase attendees.
Two EHR software vendors, Allscripts and Epic, participated in the scenario that impressed me. The first step was creation of a clinic note for an outpatient visit. This of course is passé for EHR systems, but then the magic started. A CCD summary document was created for the visit with just a few mouse clicks. Next, a referral was made to a cardiologist. This entailed pulling up a referral form to which the CCD was attached. The referral was then transmitted to the cardiologist's office using the just-released Direct (Direct Project) specification software. The sequence seemed to be nearly as easy as sending email. Recall that the purpose of the Direct Project was to develop software to enable point-to-point health information exchange in secure fashion over the Internet. My understanding is that with this design, only the envelop with the address information is visible to intermediate internet service providers. The contents, the health information, are encrypted during transmission. An exchange of certificates (used in keys in accordance with Public Key Infrastructure) is necessary to encrypt and decrypt the clinical information at either end.
The second EHR vendor's software was used in the cardiology office. Here, the cardiologist performed and documented the specialist visit. A new cardiac medication was prescribed and a new medication allergy was recorded. The medication list was reconciled against the list of medications in the CCD sent by the primary physician. Finally, a new CCD was created for the cardiology visit. The workflow was as seamless and simple as with the first vendor's EHR software.
The scenario included a transfer of care to a new primary physician needed because of a change in the patient's insurance coverage. The cardiologist's CCD was sent using Direct to the third physician office. Here, the physician's staff pre-populated the patient's new chart before the patient visit by importing data extracted from the CCD. The patient would not need to fill out history forms before the appointment and the physician would not have to enter the data into the new chart. Most of the patient's history would just need to be verified during the first visit. One can easily see how this would improve the efficiency of care and increase the satisfaction of both the patient and physician for the office visit. Most impressive for me was that both vendors have taken a software specification that was only announced a couple of weeks ago and have incorporated it and the associated workflows into their EHR systems already. (I suspect they participated in development of the Direct Project. This shows the benefit of vendor participation in public standards and interoperability activities.) I don't think it will be long before patches or updates are marketed to their customers. This sets the bar for competitors. I think we are poised for an explosion of health information exchange.
I have been a docent at the Interoperability Showcase for the last three years. I find it educational to take a tour myself occasionally. I was especially impressed by a tour I went on that demonstrated a public health scenario for newborn hearing screening. The scenario highlighted a new IHE profile that was just tested at the IHE North American Connectathon last month in Chicago. (I helped test the RFD portion of the profile.) So this was truly cutting edge technology. The profile utilizes many advanced features: generating EHR records and summary documents for mother and child (Patient Care Coordination domain), automated patient care device data capture (Patient Care Device domain), and request form for data capture (RFD-ITI infrastructure domain) with capability to pre-populate a public health form by extracting demographic data and available clinical information from the EHR. Bidirectional information exchange between provider and a public health entity is required. Finally, a clinical guideline in electronic format is used to provide clinical decision support to help a pediatrician provide the right care for a newborn with a hearing deficit.
I am convinced that the goals of improving health care through the use of health IT are not just a pipe dream. The solutions are out there being tested and demonstrated today. If you haven't ever gone to the HIMSS Interoperability Showcase, you have really missed something unique. This is where the vanguards of technology and innovation can be seen working together harmoniously. There is really no other way to see so much in one place except perhaps by attending the IHE Connectathon Conference or working at the Connectathon.
Two EHR software vendors, Allscripts and Epic, participated in the scenario that impressed me. The first step was creation of a clinic note for an outpatient visit. This of course is passé for EHR systems, but then the magic started. A CCD summary document was created for the visit with just a few mouse clicks. Next, a referral was made to a cardiologist. This entailed pulling up a referral form to which the CCD was attached. The referral was then transmitted to the cardiologist's office using the just-released Direct (Direct Project) specification software. The sequence seemed to be nearly as easy as sending email. Recall that the purpose of the Direct Project was to develop software to enable point-to-point health information exchange in secure fashion over the Internet. My understanding is that with this design, only the envelop with the address information is visible to intermediate internet service providers. The contents, the health information, are encrypted during transmission. An exchange of certificates (used in keys in accordance with Public Key Infrastructure) is necessary to encrypt and decrypt the clinical information at either end.
The second EHR vendor's software was used in the cardiology office. Here, the cardiologist performed and documented the specialist visit. A new cardiac medication was prescribed and a new medication allergy was recorded. The medication list was reconciled against the list of medications in the CCD sent by the primary physician. Finally, a new CCD was created for the cardiology visit. The workflow was as seamless and simple as with the first vendor's EHR software.
The scenario included a transfer of care to a new primary physician needed because of a change in the patient's insurance coverage. The cardiologist's CCD was sent using Direct to the third physician office. Here, the physician's staff pre-populated the patient's new chart before the patient visit by importing data extracted from the CCD. The patient would not need to fill out history forms before the appointment and the physician would not have to enter the data into the new chart. Most of the patient's history would just need to be verified during the first visit. One can easily see how this would improve the efficiency of care and increase the satisfaction of both the patient and physician for the office visit. Most impressive for me was that both vendors have taken a software specification that was only announced a couple of weeks ago and have incorporated it and the associated workflows into their EHR systems already. (I suspect they participated in development of the Direct Project. This shows the benefit of vendor participation in public standards and interoperability activities.) I don't think it will be long before patches or updates are marketed to their customers. This sets the bar for competitors. I think we are poised for an explosion of health information exchange.
I have been a docent at the Interoperability Showcase for the last three years. I find it educational to take a tour myself occasionally. I was especially impressed by a tour I went on that demonstrated a public health scenario for newborn hearing screening. The scenario highlighted a new IHE profile that was just tested at the IHE North American Connectathon last month in Chicago. (I helped test the RFD portion of the profile.) So this was truly cutting edge technology. The profile utilizes many advanced features: generating EHR records and summary documents for mother and child (Patient Care Coordination domain), automated patient care device data capture (Patient Care Device domain), and request form for data capture (RFD-ITI infrastructure domain) with capability to pre-populate a public health form by extracting demographic data and available clinical information from the EHR. Bidirectional information exchange between provider and a public health entity is required. Finally, a clinical guideline in electronic format is used to provide clinical decision support to help a pediatrician provide the right care for a newborn with a hearing deficit.
I am convinced that the goals of improving health care through the use of health IT are not just a pipe dream. The solutions are out there being tested and demonstrated today. If you haven't ever gone to the HIMSS Interoperability Showcase, you have really missed something unique. This is where the vanguards of technology and innovation can be seen working together harmoniously. There is really no other way to see so much in one place except perhaps by attending the IHE Connectathon Conference or working at the Connectathon.
Wednesday, March 2, 2011
HIMSS11 ARRA Usability Symposium
Previously I discussed the problem I was having selecting a HIMSS11 pre-conference symposium in one of my more popular blog posts. Ultimately, I chose the ARRA Usability symposium. Having attended the symposium a week ago, I am happy to say that I was satisfied with my choice. The expert speakers were almost all entertaining. I'll review some of the highlights.
The session started with a talk by Dr. Charles Friedman from the Office of the National Coordinator. He presented the first of many iterations of the definition of usability we were to hear during the day. Using a picture to represent a thousand words, he showed an image of a concert pianist playing his instrument as a metaphor for the ideal for how people should interact with health IT computer systems. He also hinted that usability criteria are being considered for official inclusion in requirements for Meaningful Use stages 2 and 3. NIST is working on methods that may be incorporated in certification test scripts for EHRs that would result in pass/not pass on usability. Dr. Friedman set the stage for a segue into presentations focused on scientific testing tools utilized by NIST and regulatory oversight for medical devices by the FDA.
I have been impressed by the work provided by NIST to support certification of EHRs for Stage 1 Meaningful Use. NIST had only a short time to ramp up staffing and deliver on their enlarged responsibility. The two NIST speakers at the symposium provided assurance that concern about EHR usability is a priority at their organization. Many have wondered if/when the FDA will assert its authority concerning EHR software as a medical device so it was interesting to hear from the FDA at this conference. Ron Kaye (no relation!) spoke about FDA oversight of EHR technology. I was disappointed that he did not bring more clarity to issues such as: 1) FDA's role in assessing and assuring EHR safety, 2) how ONC and FDA reconcile their overlapping roles, and 3) why the FDA accepts vendor attestation of usability of their systems rather than requiring independent validation (it was made clear that the role of the FDA is not to "test.") That seems a little like having the fox guard the hen house. Perhaps that explains the new direction NIST is taking to objectively test EHR usability. Symposium planners included a talk about accessibility issues and EHR software. I suspect many of us don't stop to consider the challenges in usability faced by those with disabilities. We should always consider their needs when it comes to designing computer systems.
The final talk of the morning session was by Dr. Dean Sittig. His presentation was a candid, down-to-earth discussion of HIT usability factors, with relevant examples, that resonated with experienced EHR users. Many attendees headed to lunch, shaking their heads in agreement with the points made by Dr. Sittig. This reflected their own first hand experiences with the efficiency, effectiveness, and satisfaction (or not) with the use of EHR systems (usability.)
The highlight of the symposium was hands-down the series of case studies presented after lunch. This was a lively, multi-faceted collection of real-life stories that kept everyone entertained and thereby avoided the usual post-prandial slump. The speakers represented varied points-of-view. They each filled different organizational roles.
Overall, I was happy with my choice of symposia. An excellent bibliography was provided on usability that should prove useful in the future. I previously discussed some issues of EHR usability in 2009. I wish I had clones to attend some of the symposia I reviewed previously. I hope to cover those bases by listening to the recorded sessions offered by HIMSS when they become available in a few weeks.
The session started with a talk by Dr. Charles Friedman from the Office of the National Coordinator. He presented the first of many iterations of the definition of usability we were to hear during the day. Using a picture to represent a thousand words, he showed an image of a concert pianist playing his instrument as a metaphor for the ideal for how people should interact with health IT computer systems. He also hinted that usability criteria are being considered for official inclusion in requirements for Meaningful Use stages 2 and 3. NIST is working on methods that may be incorporated in certification test scripts for EHRs that would result in pass/not pass on usability. Dr. Friedman set the stage for a segue into presentations focused on scientific testing tools utilized by NIST and regulatory oversight for medical devices by the FDA.
I have been impressed by the work provided by NIST to support certification of EHRs for Stage 1 Meaningful Use. NIST had only a short time to ramp up staffing and deliver on their enlarged responsibility. The two NIST speakers at the symposium provided assurance that concern about EHR usability is a priority at their organization. Many have wondered if/when the FDA will assert its authority concerning EHR software as a medical device so it was interesting to hear from the FDA at this conference. Ron Kaye (no relation!) spoke about FDA oversight of EHR technology. I was disappointed that he did not bring more clarity to issues such as: 1) FDA's role in assessing and assuring EHR safety, 2) how ONC and FDA reconcile their overlapping roles, and 3) why the FDA accepts vendor attestation of usability of their systems rather than requiring independent validation (it was made clear that the role of the FDA is not to "test.") That seems a little like having the fox guard the hen house. Perhaps that explains the new direction NIST is taking to objectively test EHR usability. Symposium planners included a talk about accessibility issues and EHR software. I suspect many of us don't stop to consider the challenges in usability faced by those with disabilities. We should always consider their needs when it comes to designing computer systems.
The final talk of the morning session was by Dr. Dean Sittig. His presentation was a candid, down-to-earth discussion of HIT usability factors, with relevant examples, that resonated with experienced EHR users. Many attendees headed to lunch, shaking their heads in agreement with the points made by Dr. Sittig. This reflected their own first hand experiences with the efficiency, effectiveness, and satisfaction (or not) with the use of EHR systems (usability.)
The highlight of the symposium was hands-down the series of case studies presented after lunch. This was a lively, multi-faceted collection of real-life stories that kept everyone entertained and thereby avoided the usual post-prandial slump. The speakers represented varied points-of-view. They each filled different organizational roles.
Overall, I was happy with my choice of symposia. An excellent bibliography was provided on usability that should prove useful in the future. I previously discussed some issues of EHR usability in 2009. I wish I had clones to attend some of the symposia I reviewed previously. I hope to cover those bases by listening to the recorded sessions offered by HIMSS when they become available in a few weeks.
Tuesday, March 1, 2011
The Direct Project Goes Live
For those not familiar with the Direct Project, it started out about a year ago as NHIIN Direct and then was renamed several months ago. The goal was to collaboratively develop a specification to enable point-to-point health information exchange for providers, patients, and others. The timetable for this project seemed awfully ambitious to me, but I was wrong. There were several main drivers: the meaningful use stage 1 requirements for information exchange capabilities, the desire to use existing technologies to reach the goal, and a philosophy to make sure to incorporate the needs of "the little guy." Now, it is just a year later and the first pilot implementations of the Direct Project are being rolled out. By any measure, this is an impressive accomplishment.
Early on, the project work group went through a lively discussion concerning adoption of the transport standard to be used. SOAP, REST, and SMTP were among the protocols considered. Finally a consensus was reached to adopt SMTP with s/mime for security. Once SMTP was selected, the project moved forward more rapidly and with less controversy. The specification enables point-to-point exchange of a variety of health information in a fashion similar to email.
The pilots that have been announced to date seem designed to fulfill relatively limited use cases. Uses of Direct will expand rapidly as the safety and efficacy of the project are validated by experience gained in the production environment. Vendors will need to implement Direct software specification in their systems and an infrastructure of HISPs (Heath Internet Service Providers) will need to be established to serve all areas of the country.
In his Halamka blog Dr. John Halamka explained how the Direct specification was used to send data from his CCD/CCR at BIDMC to his PHR in Microsoft Health Vault. It took engineers at both ends about a day to get all the configurations set up. Certificate management had to be accomplished. When they were done, he was then able to extract "atomically" section data from the summary documents and organize it in a manner that gave him great flexibility in managing his health information in the PHR. The workflow to update the PHR sounds manual now but it could be automated for future uses. This potentially removes one of the barriers for more widespread adoption of PHRs by the public. Until now, it has been very difficult to import and organize personal health data.
The Direct Project removes an important barrier to more widespread information exchange. I am enthusiastic about its potential. It uses open source software and appears to be relatively easy to implement because existing technology is utilized. I am sure that many clinicians, especially those in small organizations and practices, will use Direct for their information exchange needs in the near future. But there are some caveats. EHR vendors will need to incorporate the software into their systems. (Epic and Allscripts, for example, demonstrated impressively the use of Direct at HIMSS11 Interoperability Showcase last week.) Will this trigger a need to update certification of the EHR software? As more sites use the specification another problem can be anticipated. One needs to know addressing information for the point-to-point exchange. Address management was not an issue addressed by the Direct Project. In other words, provider directories were not included in the specification. So users will need to develop a means to store frequently used addresses (a contact list like that included in many email programs) and an easy way to discover unknown addresses. Finally, Direct utilizes a "push" mechanism. Queries for data about a patient are not possible. Direct may not work well for after hours information exchange needs or for use in emergency situations.
My prediction is that the Direct Project will be utilized by many organizations intending to jump start meaningful health information exchange. The business case for its use is less complicated than for many more capable models for health information exchange. The Direct Project has proved to be the paradigm case for the successful, rapid, development of health information technology projects through a public-private collaborative. It should serve as a model for future health IT projects of similar scope. See the ONC video announcing early success with the project Direct Project Video.
Early on, the project work group went through a lively discussion concerning adoption of the transport standard to be used. SOAP, REST, and SMTP were among the protocols considered. Finally a consensus was reached to adopt SMTP with s/mime for security. Once SMTP was selected, the project moved forward more rapidly and with less controversy. The specification enables point-to-point exchange of a variety of health information in a fashion similar to email.
The pilots that have been announced to date seem designed to fulfill relatively limited use cases. Uses of Direct will expand rapidly as the safety and efficacy of the project are validated by experience gained in the production environment. Vendors will need to implement Direct software specification in their systems and an infrastructure of HISPs (Heath Internet Service Providers) will need to be established to serve all areas of the country.
In his Halamka blog Dr. John Halamka explained how the Direct specification was used to send data from his CCD/CCR at BIDMC to his PHR in Microsoft Health Vault. It took engineers at both ends about a day to get all the configurations set up. Certificate management had to be accomplished. When they were done, he was then able to extract "atomically" section data from the summary documents and organize it in a manner that gave him great flexibility in managing his health information in the PHR. The workflow to update the PHR sounds manual now but it could be automated for future uses. This potentially removes one of the barriers for more widespread adoption of PHRs by the public. Until now, it has been very difficult to import and organize personal health data.
The Direct Project removes an important barrier to more widespread information exchange. I am enthusiastic about its potential. It uses open source software and appears to be relatively easy to implement because existing technology is utilized. I am sure that many clinicians, especially those in small organizations and practices, will use Direct for their information exchange needs in the near future. But there are some caveats. EHR vendors will need to incorporate the software into their systems. (Epic and Allscripts, for example, demonstrated impressively the use of Direct at HIMSS11 Interoperability Showcase last week.) Will this trigger a need to update certification of the EHR software? As more sites use the specification another problem can be anticipated. One needs to know addressing information for the point-to-point exchange. Address management was not an issue addressed by the Direct Project. In other words, provider directories were not included in the specification. So users will need to develop a means to store frequently used addresses (a contact list like that included in many email programs) and an easy way to discover unknown addresses. Finally, Direct utilizes a "push" mechanism. Queries for data about a patient are not possible. Direct may not work well for after hours information exchange needs or for use in emergency situations.
My prediction is that the Direct Project will be utilized by many organizations intending to jump start meaningful health information exchange. The business case for its use is less complicated than for many more capable models for health information exchange. The Direct Project has proved to be the paradigm case for the successful, rapid, development of health information technology projects through a public-private collaborative. It should serve as a model for future health IT projects of similar scope. See the ONC video announcing early success with the project Direct Project Video.
Subscribe to:
Posts (Atom)
Posts
