There have been several posts on the blogs I read that have commented on the discussion of imaging at the January meeting of the Health Information Technology Standards Committee (HITSC.) I am frankly a little surprised that this issue has not been raised more forcefully in the last 18 months. Those familiar with the Meaningful Use regulations are aware that imaging standards were not addressed in Stage 1. Imaging is not due for serious consideration until Stage 3 in 2015 according to initial plans. This seems to constitute a significant oversight to me. Let me explain how I see it.
Some form of imaging is used in many hospitals, outpatient primary care, and outpatient specialist patient visits. The variety of patient data stored as images has exploded in recent years. X-rays are now only one of a variety of the types of images needed for patient care. Now images may include x-rays, MRI/CT scans, nuclear medicine studies, electrocardiography, fetal monitoring strips, clinical photographs, photomicrographs, endoscopy video, and more. The old maxim "a picture is worth a thousand words" is especially true in modern medical care.
A number of logical arguments can be made to support federal policy and incentives that would promote the sharing of imaging data. Imaging information has an innate value with respect to patient care decision making and management of problems comparable to that of laboratory results. We have a very mobile population in the US so it is important to develop methods to mitigate geographic silos of imaging information that currently cannot follow patients easily. Imaging data can be foundational to studies in the fields of health care research and public health. Images that can cross the boundaries of individual health care provider organizations will be important for situational awareness in the patient centered medical home model. I assert that safe, efficient, timely, and effective clinical care requires the ability for providers to exchange images through use of the HIT systems. I am prepared to back this up with examples from my recent experience providing clinical care to patients.
As a practicing orthopedic surgeon, I depend on images to treat nearly every one of my patients. Many x-rays are taken at outside facilities-hospitals, free standing imaging centers, urgent care centers, and other physician offices. Frequently, the studies I need are not available for a variety of reasons- the patient is visiting from another geographic area and did not bring the films, the patient forgot to pick up the films or CD from their provider, they bring a CD but because every vendor has proprietary PACS viewing software, those images are hard to access or worse, my system crashes when I try to view the images on the CD. On the other hand, when the x-rays are brought on film, they are hard to organize and finding storage space for the x-ray folders is problematic. When previous images are not available then often the studies must be repeated. This adds to the risks (more x-ray exposure) and expense of the medical care I deliver. Each of the issues I have discussed can be correlated with one or more of the 5 Meaningful Use priority health policy outcomes, goals, and objectives.
I have the sense that there has been a strong primary care bias in the selection of Meaningful Use criteria. When there is the perception that primary providers don't need a capability, then the information technology standards and requirements related to that capability are not included in the regulations. I think there is a mistake here. There has been a trend for primary clinicians to simply read imaging reports rather than to review the images themselves. This may be a reflection of limited training many clinicians receive in their training. Nevertheless, when primary care clinicians review images, not just the reports, they expand their understanding of a patient's disease and also provide an important second look at images that serves as a valuable check and balance to ensure the safety and quality of the care they provide.
In my opinion ONC, the Health Information Technology Standards Committee and the Health Information Technology Policy Committee should make the ability to exchange images a high priority for Meaningful Use Stages 2 and 3. Standards for image exchange must be selected. Transport mechanisms via health information exchange should be supported and promoted even more vigorously.
Thursday, January 27, 2011
Sunday, January 23, 2011
Dr. Bob HIT Thoughts Blog Index 2009 and 2010
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
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 Workforce Training Dec. 27, 2009
HIT Workforce Training Dec. 14, 2009
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
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
Planning for HIMSS11 Dec. 1, 2010
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
Thought on the NHIN Mar. 18, 2010
Breach Notification-Part 2 Oct. 26, 2009
Certification July 29, 2009
Certification Follow-up Aug. 19, 2009
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 Workforce Training Dec. 27, 2009
HIT Workforce Training Dec. 14, 2009
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
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
Planning for HIMSS11 Dec. 1, 2010
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
Thought on the NHIN Mar. 18, 2010
Saturday, January 22, 2011
NA Connectathon 2011
I have just returned from my third IHE Connectathon. It was a satisfying week characterized by gaining experience with profiles new to me, collaboration with skilled vendor staff, and meeting new friends. Starting Monday, I immediately developed a schedule of early morning workouts at the hotel fitness center followed by a quick shower and then a stroll outside, across the Chicago River to the north to find some sustenance. Then it was back to the hotel to start the morning testing session. Following this adjourned to the dining area for the proverbial free lunch. Fighting the postprandial slump, we went back to work until dark completing the afternoon testing. I finished up the day with a light dinner and some reading/writing. Lastly, it was off to bed for some rest and the beginning of another cycle.
Here are some of my observations garnered by my experiences this year. I performed a potpourri of testing in both the PCC (Patient Care Coordination) and QRPH (Quality, Research, and Public Health) domains.
PCC document creation and display: Vendors who have been to previous Connectathons have these tests down to a science. It feels great to test documents that fly through the NIST and content tests with no errors. On the other hand, some of the attendees seem to be poorly prepared. A few haven't even run their documents through the easily accessed tools to self-test ahead of the Connectathon. It makes one wonder what they are thinking! Here is a dilemma to consider concerning the Connectathon testing requirements.
A large number of tests involve what is called the "process document" procedure. Those of you familiar with CDA/C32/CCD will immediately understand what I describe below. Vendors pull documents produced by their fellow vendors from a repository and then demonstrate one of the following options- view document, import document, import section, or import discrete data. Everyone can demonstrate the view option. This would be only somewhat helpful in a clinical environment. It would be the same as having a patient bringing an envelope to Dr. X with a copy of a clinic note from Dr. Y for Dr. X to take a look at but then folding up the document and taking it home. In most cases, Dr. X would find the information more useful if it could be copied and attached to the patient's chart in the outside records section where it would be available to review later if needed (the import document option.) The import section option could be used to improve practice efficiency. For example, past history information could be cut and pasted from Dr. Y's records into a new history and physical form used by Dr. X. Dr. X would still need to verify the accuracy of the information but would not need to collect all the past history information de novo. Patients especially would appreciate this capability. Finally, I think the most useful option will be the ability to import discrete data and attach it to a patient's chart. There are many potential uses. Automated reconciliation processes for information about one patient, from different sources, will depend on it. The ability to graphically display information from different sources will require the ability to manage discrete data. Finally, many clinical decision support systems will require the ability to import discrete data. I think IHE should raise the bar on testing requirements, requiring the more advanced capabilities, in order to promote a vision in which health information technology systems are able to interoperate seamlessly to improve the safety, quality, and efficiency of patient care.
The astute will recognize that my recommendation anticipates rapid progress in the development of health information exchanges. We all recognize there are many unresolved issues concerning HIE such as governance, policy, trust, consent, etc. I think technical issues could be solved pending resolution of the more thorny controversies.
CRD (clinical research document) and DSC (drug safety content): These are relatively new content profiles for Connectathon testing. The content creators seemed have more difficulty delivering conforming documents for these profiles. Most completed the re-work effort needed to complete testing during the Connectathon though. Hopefully, testing of CRD and DSC will go more smoothly next year. Also, a NIST CDA tool option specific for the IHE DSC profile needs to be developed to make the testing more robust.
RFD (request form for data capture): This is a really cool profile that was new to me this year. Even after completing Connectathon tests, I can not say I fully understand how it works. I do know that RFD will turn out to be a terrific profile for use in public health, research, and possibly quality fields. Read through the use cases to gain an understanding of the facility of this profile.
I had fun doing the testing because success required actual, real-time interoperability involving two to four vendors, using the content requirements and available infrastructure. Test partners had to collaborate to solve infrastructure configuration challenges. These were dynamic demonstrations like you will see at the HIMSS Interoperability Showcase, not just mundane lab tests. I am especially interested in usability/user interface challenge. I have written about once or twice in the past year or so. I got a kick out of seeing the careful, thoughtful design incorporated into the displays by some vendors. They appeared so intuitive that even a technologically challenged MD could use them without the need to even consider the technical aspect running on the backend. For other vendor's setups, one would need to be a computer programmer to get them to work.
Summing it up: I learned a lot about the challenges of interoperability again this year. Communication is almost always the major issue. Some of the profiles are not as specific or as clear as they could be. Optionality in standards always introduces elements of uncertainty in interpretation and implementation. We saw this demonstrated over and over.
As in all human endeavors, the personalities of those we work with can have a big influence. Some monitors were easier to work with than others. My satisfaction and enjoyment of the Connectathon came from the interaction with certain vendor's representatives and with a few special fellow monitors. I would like to specifically mention Lisa Nelson from IHE who was instrumental in organizing the PCC and QRPH monitor efforts and Steve Moore, our fearless overall monitor leader. Fellow monitors Monique Speight, Andrew McCaffrey, Didi Davis, and Philip DePalo helped make this year's Connectathon memorable.
Here are some of my observations garnered by my experiences this year. I performed a potpourri of testing in both the PCC (Patient Care Coordination) and QRPH (Quality, Research, and Public Health) domains.
PCC document creation and display: Vendors who have been to previous Connectathons have these tests down to a science. It feels great to test documents that fly through the NIST and content tests with no errors. On the other hand, some of the attendees seem to be poorly prepared. A few haven't even run their documents through the easily accessed tools to self-test ahead of the Connectathon. It makes one wonder what they are thinking! Here is a dilemma to consider concerning the Connectathon testing requirements.
A large number of tests involve what is called the "process document" procedure. Those of you familiar with CDA/C32/CCD will immediately understand what I describe below. Vendors pull documents produced by their fellow vendors from a repository and then demonstrate one of the following options- view document, import document, import section, or import discrete data. Everyone can demonstrate the view option. This would be only somewhat helpful in a clinical environment. It would be the same as having a patient bringing an envelope to Dr. X with a copy of a clinic note from Dr. Y for Dr. X to take a look at but then folding up the document and taking it home. In most cases, Dr. X would find the information more useful if it could be copied and attached to the patient's chart in the outside records section where it would be available to review later if needed (the import document option.) The import section option could be used to improve practice efficiency. For example, past history information could be cut and pasted from Dr. Y's records into a new history and physical form used by Dr. X. Dr. X would still need to verify the accuracy of the information but would not need to collect all the past history information de novo. Patients especially would appreciate this capability. Finally, I think the most useful option will be the ability to import discrete data and attach it to a patient's chart. There are many potential uses. Automated reconciliation processes for information about one patient, from different sources, will depend on it. The ability to graphically display information from different sources will require the ability to manage discrete data. Finally, many clinical decision support systems will require the ability to import discrete data. I think IHE should raise the bar on testing requirements, requiring the more advanced capabilities, in order to promote a vision in which health information technology systems are able to interoperate seamlessly to improve the safety, quality, and efficiency of patient care.
The astute will recognize that my recommendation anticipates rapid progress in the development of health information exchanges. We all recognize there are many unresolved issues concerning HIE such as governance, policy, trust, consent, etc. I think technical issues could be solved pending resolution of the more thorny controversies.
CRD (clinical research document) and DSC (drug safety content): These are relatively new content profiles for Connectathon testing. The content creators seemed have more difficulty delivering conforming documents for these profiles. Most completed the re-work effort needed to complete testing during the Connectathon though. Hopefully, testing of CRD and DSC will go more smoothly next year. Also, a NIST CDA tool option specific for the IHE DSC profile needs to be developed to make the testing more robust.
RFD (request form for data capture): This is a really cool profile that was new to me this year. Even after completing Connectathon tests, I can not say I fully understand how it works. I do know that RFD will turn out to be a terrific profile for use in public health, research, and possibly quality fields. Read through the use cases to gain an understanding of the facility of this profile.
I had fun doing the testing because success required actual, real-time interoperability involving two to four vendors, using the content requirements and available infrastructure. Test partners had to collaborate to solve infrastructure configuration challenges. These were dynamic demonstrations like you will see at the HIMSS Interoperability Showcase, not just mundane lab tests. I am especially interested in usability/user interface challenge. I have written about once or twice in the past year or so. I got a kick out of seeing the careful, thoughtful design incorporated into the displays by some vendors. They appeared so intuitive that even a technologically challenged MD could use them without the need to even consider the technical aspect running on the backend. For other vendor's setups, one would need to be a computer programmer to get them to work.
Summing it up: I learned a lot about the challenges of interoperability again this year. Communication is almost always the major issue. Some of the profiles are not as specific or as clear as they could be. Optionality in standards always introduces elements of uncertainty in interpretation and implementation. We saw this demonstrated over and over.
As in all human endeavors, the personalities of those we work with can have a big influence. Some monitors were easier to work with than others. My satisfaction and enjoyment of the Connectathon came from the interaction with certain vendor's representatives and with a few special fellow monitors. I would like to specifically mention Lisa Nelson from IHE who was instrumental in organizing the PCC and QRPH monitor efforts and Steve Moore, our fearless overall monitor leader. Fellow monitors Monique Speight, Andrew McCaffrey, Didi Davis, and Philip DePalo helped make this year's Connectathon memorable.
Wednesday, January 12, 2011
Health IT Ontologies of the Future
Traditionally listed as a part of the major branch of philosophy known as metaphysics, ontology deals with questions concerning what entities exist or can be said to exist, and how such entities can be grouped, related within a hierarchy, and subdivided according to similarities and differences.(http://en.wikipedia.org/wiki/Ontology)
One of the foundational elements of interoperability in health IT is the development of standards. Standards are usually developed around specific use cases. Standards are developed by Standards Development Organizations (SDOs). Isolated, single standards are not very useful in real life. However, when several standards are assembled in a system to work together then a lot can be accomplished. The work of organizing collections of standards that work together is done by standards harmonizing organizations. Often, they work from goals or use cases that define a business purpose. Some of the better-known examples of organizations that harmonize standards in the health care field are HITSP (no longer active) and Integrating the Healthcare Enterprise (IHE.) If you review the work products of SDOs and harmonization organizations, two things become apparent: 1) The products of their efforts become increasingly complex and, 2) many existing standards or components are repurposed/reused for new tasks. This causes problems for intended users.
The standards harmonization publications usually just reference the original standards. This is done for two primary reasons. First, many standards are proprietary and therefore are often not available unless license fees are paid by the users. Next, the publications would become unmanageably large if each of the separate standards documents was included. Implementers have a valid claim that they have to search in many different places to find all the documentation. Even then, necessary information might not be available publicly.
A number of approaches have been recommended to solve the problems. First, it is essential that open health care standards be adopted and be made available to developers and implementers. The challenge is to settle on a business model that solves the financial issues related to intellectual property. Ultimately, users will have to pay, either directly or indirectly. I think the Federal government will become more involved in the near future. The second issue is the real focus of this blog. Current documentation methods, such as documents, spread sheets, tables, and even more complicated programs do a poor job of graphically portraying the complex relationships involved in harmonized standards. It is hard to navigate the layers and drill down to the fine details when that is needed. This became clear to me during the final six months of HITSP activity while I listened in on teleconference sessions of the workgroup dealing with the standards harmonization framework. Few have utilized programs such as Protégé that were specifically designed to manage ontologies. Ontologies, like neural networks, do not lend themselves well to representation on a flat sheet of paper. I am going to go out on a limb and predict a revolution in graphical knowledge representations, transitioning from 2-D to 3-D in the next few years. We have already seen the leap to 3-D in movie making, computer gaming, and television set design. I do not think that it will be much of a stretch for developers to produce new software that will allow graphic representation of complexes of standards with imbedded knowledge content that can be selected and viewed. Just as an example, imagine how much easier it would be to view the route maps of the large airlines in 3-D rather than the confusing flat maps that we find in the back of airline magazines now. We should have tools to manipulate the views, change our point of view, find information about the terminals at either end of a route, and review the types of aircraft used for particular routes along with the schedule and gate information. Hopefully this analogy provides an idea of what I envision. I think the development of 3-D software to represent ontologies of standards, their relationships, and associated knowledge content and the availability of open standards will make the work of implementers much easier in the future.
One of the foundational elements of interoperability in health IT is the development of standards. Standards are usually developed around specific use cases. Standards are developed by Standards Development Organizations (SDOs). Isolated, single standards are not very useful in real life. However, when several standards are assembled in a system to work together then a lot can be accomplished. The work of organizing collections of standards that work together is done by standards harmonizing organizations. Often, they work from goals or use cases that define a business purpose. Some of the better-known examples of organizations that harmonize standards in the health care field are HITSP (no longer active) and Integrating the Healthcare Enterprise (IHE.) If you review the work products of SDOs and harmonization organizations, two things become apparent: 1) The products of their efforts become increasingly complex and, 2) many existing standards or components are repurposed/reused for new tasks. This causes problems for intended users.
The standards harmonization publications usually just reference the original standards. This is done for two primary reasons. First, many standards are proprietary and therefore are often not available unless license fees are paid by the users. Next, the publications would become unmanageably large if each of the separate standards documents was included. Implementers have a valid claim that they have to search in many different places to find all the documentation. Even then, necessary information might not be available publicly.
A number of approaches have been recommended to solve the problems. First, it is essential that open health care standards be adopted and be made available to developers and implementers. The challenge is to settle on a business model that solves the financial issues related to intellectual property. Ultimately, users will have to pay, either directly or indirectly. I think the Federal government will become more involved in the near future. The second issue is the real focus of this blog. Current documentation methods, such as documents, spread sheets, tables, and even more complicated programs do a poor job of graphically portraying the complex relationships involved in harmonized standards. It is hard to navigate the layers and drill down to the fine details when that is needed. This became clear to me during the final six months of HITSP activity while I listened in on teleconference sessions of the workgroup dealing with the standards harmonization framework. Few have utilized programs such as Protégé that were specifically designed to manage ontologies. Ontologies, like neural networks, do not lend themselves well to representation on a flat sheet of paper. I am going to go out on a limb and predict a revolution in graphical knowledge representations, transitioning from 2-D to 3-D in the next few years. We have already seen the leap to 3-D in movie making, computer gaming, and television set design. I do not think that it will be much of a stretch for developers to produce new software that will allow graphic representation of complexes of standards with imbedded knowledge content that can be selected and viewed. Just as an example, imagine how much easier it would be to view the route maps of the large airlines in 3-D rather than the confusing flat maps that we find in the back of airline magazines now. We should have tools to manipulate the views, change our point of view, find information about the terminals at either end of a route, and review the types of aircraft used for particular routes along with the schedule and gate information. Hopefully this analogy provides an idea of what I envision. I think the development of 3-D software to represent ontologies of standards, their relationships, and associated knowledge content and the availability of open standards will make the work of implementers much easier in the future.
Subscribe to:
Posts (Atom)