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.
Showing posts with label RFD. Show all posts
Showing posts with label RFD. Show all posts
Thursday, March 3, 2011
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.
Subscribe to:
Posts (Atom)
Posts
