Oncologists Need Hands-on Approach in Developing Next Generation of EHRs

A health information technology (HIT) innovator advises oncologists to take an active part in their electronic health record (EHR) development process.


Get Permission

2.18.50_hughes.jpgThe electronic health record system offered by vendors is more like a filing cabinet, not the sophisticated, interactive database needed by busy oncologists, according to Kevin S. Hughes, MD, FACS, Co-Director, Avon Comprehensive Breast Evaluation Center, Massachusetts General Hospital, who presented a session titled “Beyond the EHR,” at the recent ASCO HIT/EHR symposium in Atlanta.

Specialty-specific Interfaces Needed

“The promise of the EHR is to increase efficiencies, reduce costs, and increase quality. However, those goals can be accomplished only if the software takes into account the specific needs of oncology workflow and data collection,” Dr. Hughes explained.

“Every specialist needs a specialty-specific interface; EHR vendors do not have the wherewithal to create thousands of specific interfaces while trying to build the basic infrastructure,” Dr. Hughes commented, adding, “Moving forward, each medical specialty should help build their own specific EHR interfaces that complement the practice’s office flow and patient data needs.”

Talking to Each Other

2.18.50_chart.jpgTo avoid creating a massive HIT Tower of Babel, EHRs from across oncologic disciplines need to be able to “talk to each other.” But Dr. Hughes contended that depending on EHRs that are designed and built as proprietary products by vendors that want to protect their investments would ultimately make it harder to interoperate across the oncology community. “We need to ensure that EHRs are built with a relatively open data structure that allows one to seamlessly access and interact with the information. This is doable on a large scale across oncologic disciplines. Its going to take considerable time and investment, and it has to be done by a large number of vendors supplying nimble EHRs and working closely with the specialists who use them,” Dr. Hughes said.

As examples of successful central databases working with interoperable software packages, Dr. Hughes pointed to the breast imaging, anesthesia, and pathology communities. These specialties have set up their own databases and interfaces to deal with their unique needs. They generate and send free text reports into the EHR, as the basic document management systems lack the ability to accept these data.

“These disciplines have developed specialty-specific software that is database-driven. The oncology community could definitely build these types of interoperable systems at whatever level an existing EHR can manage, but currently that level tends to be pretty taxed,” Dr. Hughes commented.

He posited that future e–health care would be comprised of a large number of specialty-specific software packages that connect to a central EHR, which becomes the community database, a nexus for clinical communication.

Quality Outcomes/Clinical Decisions

The core component of EHR-driven quality care is the clinical decision support functionality. “Current EHRs succeed in being a document repository that allows practitioners to view information from multiple areas. But EHRs cannot move to the next level of communication until they adopt a clinical decision support functionality,” Dr. Hughes said.

Dr. Hughes stressed that the physicians using the EHRs are the only ones capable of implementing the clinical decision support functions. Major vendors cannot set the standards for how to care for the complex needs of patients with cancer. To that end, Dr. Hughes along with several collaborators designed a cancer risk assessment software system (HughesRiskApps Breast Surgery Module) for clinical decision support that helps identify and manage women at high risk for hereditary breast and ovarian cancer.

“The module, which is in use throughout the country, separates out the clinical pieces and makes those pieces interoperable,” Dr. Hughes said. “We’re trying to show that surgery-specific interfaces and specialty-specific decision support can be created and made HL7-compliant so they can interact with other software packages.” [Editor’s Note: Health Level Seven International (HL7) is the global authority on standards for interoperability of health information technology, with members in more than 55 nations. HL7 promotes the use of informatics to increase clinical effectiveness.]

Breast Model as Prototype

2.18.51_quote-b.jpg“Although we follow a relatively simple method, few others around the nation seem to be doing it. Rather than a physician taking a history verbally and then transcribing the patient information into the EHR, we begin with the patient entering her own information on a user-friendly tablet PC questionnaire,” Dr. Hughes said.

He explained that they also use data that is already stored in the EHR, including a problem list of medication alerts and other pertinent clinical issues. “When you mix the stored data with the patient’s input, you get a fairly comprehensive clinical picture of the patient’s real-time status. The clinician then does further editing and enhancement of the information, inputting data that only doctors would know,” Dr. Hughes said.

“The patient/doctor and EHR-stored data are aggregated into a package. We then run clinical decision support on that package to individualize a surgical management strategy for that particular patient. We still live in a world that needs documentation, so at this point, we generate all the necessary orders and documents,” Dr. Hughes commented.

“Following this simple but thorough pathway … creates a relatively seamless course that reduces labor and costs, and increases the ability of busy doctors to deliver high-quality care. We developed this breast surgery module as the prototype, but we plan to move into other disciplines that treat breast cancer, as there is significant overlap of data and, ideally, it will serve as a module to any EHR,” Dr. Hughes said. ■

Disclosure: Dr. Hughes is the inventor of HughesRiskApps, a freeware software system.  He receives salary support from this effort and potentially will receive royalties for commercial use of the software.



Advertisement

Advertisement



Advertisement