Gerry Higgins, Director, Translational Informatics, Johns Hopkins Medicine
Over the past several years, we have seen segmentation of EHR product offerings, usually tailored for different clinical settings. In a domain such as Radiology, the specialty requires integration of PACS into the EHR. However, in certain specialties such as oncology, the federal government, professional organizations, and even patient advocacy groups have recommended that the so-called patient-centric EHR requires different functionality than a “one size fits all” EHR. Thus was born CORE, or Clinical Oncology Requirements for the EHR. It was forged from collaboration between the American Society of Clinical Oncology (ASCO) and caBIG (the Cancer Bioinformatics Grid), based at the National Cancer Institute. Several vendors now offer an Oncology EHR.
The rationale is as follows:
- Oncology and cancer care require different clinical workflow than other specialties – especially in regards to the administration of chemotherapy.
- An objective of caBIGis to develop an interoperable framework that connects all of the components of the cancer community — including clinical care, biomedical research, and the regulatory domain. They can provide an interoperable Oncology EHR to meet the needs of the oncologist and, through association, the cancer patients themselves.
On a personal note, when a family member developed breast cancer in 2006, Johns Hopkins Hospital provided her with a password-protected web page that included all of the details of her diagnosis, as well as prognosis of therapeutic outcome based on choice of doing nothing, having a mastectomy, chemotherapy, radiation or a combination of therapies. Thankfully she is in remission. The point is, I can see the relevance of an Oncology EHR to the clinician, but a dedicated web site and/or a Personal Health Record (PHR) would probably be a more digestible solution for the patient.
But wait – it doesn’t stop here. There is now a recommendation from the National Institute of Mental Health that a Psychiatric EHR be developed; emphasizing the inclusion of complex functional brain imaging that goes beyond what is now normally contained in a radiology report or as PACS imagery in an EHR, with a more intensive focus on medication and patient follow-up care and compliance.
In regards to caBIG – although it is a tremendous toolkit and network for bioinformatics, and elements of it are being used for drug discovery in Biotech and Pharmaceutical companies, how much of this work has really filtered down to the hospital oncologist or other specialist for improved clinical practice? I must admit that I have a foot in two domains: bioinformatics and clinical informatics. It has been my observation that biomedical researchers in academic medical or federal research institutions have developed intelligent software applications that can be used to understand complex genomic, proteomic and metabolomic pathways, and associate specific genetic alleles with specific diseases. The National Institutes of Health created the Clinical and Translational Science Awards (CTSA), for funding up to 60 of the nation’s medical schools to perform research and “translate” basic biomedical research to the clinic, the notorious “bench to bedside.”
Maybe we need a translator to translate basic biomedical research discovery, which is evolving at an incredible pace, to the clinician that works in one of the 5,000 U.S. hospitals that are not tightly coupled to an academic medical center?
Is a specialty-specific EHR the correct solution for every practicing clinician? Have we thoroughly investigated the rapidly changing workflow in a variety of clinical practice settings that could benefit from bioinformatics?
And finally, what are we going to provide to the patient? A PHR tethered to a specialty-specific EHR? The ‘Medical Home’ concept being tried in TRICARE in the U.S. military? (see http://www.defense.gov/news/newsarticle.aspx?id=55362)
I don’t know the answers, and I may be naïve about the current state-of-the-art in the EHR world, but I can tell you that a bioinformatics software solution being “thrown over the wall” to the clinic is not going to work. I am not as worried about interoperability issues, although these are considerable, but whether the physician will embrace the vast amount of new biological information coming down the pipeline from a somewhat incomprehensible source.
Evan Steele, CEO SRSsoft says
Gerry Higgins is spot-on. Unfortunately, there is still a ‘one size fits all’ mentality among hospital CIOs. I believe that in due course, hospital CIOs will come to grips with the fact that mass numbers of ambulatory specialty practices in their communities have enormous amounts of valuable data trapped in paper charts. Hospitals will then start offering specialty-specific EHRs to tap into this data.
donrule says
When you look at the history of business systems this isn’t what has happened. It was typical in the 1980’s to buy “best of breed”. IT people were faced with an interoperability nightmare – but more importantly end users were faced with the cost of learning multiple systems. Then more integrated (e.g. AP/GL/Purchasing)systems evolved. They were totally dismissed by end users until economic necessity made it impossible to continue the culture of infinite customization.
A similar thing happed with Microsoft Office. When it first shipped there were better solutions for any component part but the combination of a common user experience and near ubiquitous installation created a certain “software Gestalt”.
Will bioinformatics require a specialized system?
Bioinformatics are not very powerful without access to the clinical data. Even the most rudimentary decision (say Warfarin dosing) requires patient demographics and from a systemic standpoint it makes more sense to merge the genetic/proteomic/etc. data into the existing record than some separate system.
What I expect is a world with fewer user-facing pieces that integrate with more external services. So in my case a non-specific EMR will offer decision support that queries my system to provide the best of breed in bioinformatics.
I agree with Evan that one size does not fit all but I think that there is strong historical precident for fewer systems and not more.
Gerry Higgins says
Don-
I agree that there will be fewer EHR and CPOE product offerings as the healthcare IT market undergoes consolidation (M&A). Also, I agree that most clinicians require a parsimonious interface.
However, I would disagree with you on 2 issues:
(1) The Oncology EHR/CPOE is already installed in settings such as Johns Hopkins hospital. For example, it routinely checks for CYP2D6 allelic variation when a patient is co-prescribed Tamoxifen with an SNRI like Cymbalta, which can block Tamoxifen metabolism.
(2) Silos of diffent bioinformatics software, even the commonly used i2b2 application, are very complex and usually do not provide a comprehensible and usable interface for the clinician. Even though bioinformatics requires patient data, there is often a reliance on deidentified data from sources such as biobanks, and very little pull from co-existing EHR databases, even from clinical settings in academic research centers (not to mention all the other hospitals and clinics).
So, in the long run, I think that you are correct. However, it is my belief that in the intervening 5-10 years, there is a requirement for application development in the gap between bioinformatics and clinical informatics (2 very different domains), where specialty-specific EHRs may be the answer.
Lynn H. Vogel, Ph. D. says
Unfortunately when we talk about “merging” data, we continue to be locked into architectural thinking that is now over two decades old–but one that unfortunately continues to be used by all of the major commercial clinical systems vendors. While data persistence is required in some cases, there are archtectural frameworks (especially Services Oriented Architectures) that now permit data to be published and consumed without necessariliy being merged. This is increasingly the standard for software development outside of healthcare, but not yet in healthcare. As data from research processes (such as genomic expression patterns and other -omic sources) become more and more a necessary compent of the clinical workflow, architecture will become a more important and visible challenge for commercial system vendors. At MD Anderson we have been working with SOA for several years, have an inhouse EMR (known as ClinicStation) developed within an SOA framework, and are now doing the same for research processes (called ResearchStation), also using SOA, and it actually works. I do think this is the future; still unknown is whether the commercial vendors will be able to respond.
Gerry Higgins says
Dr. Vogel-
I agree with you. I have been President of a Biotech/Medical Products company in the past, and we used SOA, as we do with our site: http://www.warfarindosing.org (Kriag Robson, Dr. Brian Gage). I would suggest that it is the Healthcare IT vendors such as those that provide EHR products are lost in the past (maybe with the exception of Microsoft’s Amalga(R)).
But I see a bigger problem with the content, not the architecture. In Bioinformatics, there are multiple designations for the same genes, transcripts and proteins, depending on where you obtain the data. Thus, there has to be some standardization of nomenclature within the bioinformatics community – they have to use the same descriptors.
Finally, there is no standard for displaying genomic data in the EHR. Currently, it is entered as free text, which may be fine until we have to use it in some more structured form.