Poor portal design has lots to blame for messaging issues. In the portals that I have used, the patient can…
Readers Write: Enabling Clinically Intelligent EHRs
Enabling Clinically Intelligent EHRs
By David Lareau
David Lareau is CEO of Medicomp Systems of Chantilly, VA.
A key takeaway from John Glaser’s recent article in the Harvard Business Review, “It’s Time for a New Kind of Electronic Health Record,” is that it is time for EHRs to leverage clinical intelligence for analysis of patient data and to address clinicians’ usability concerns.
Current systems were designed to track transactions to generate and justify billable events. They are, in fact, organized as a set of separate “buckets,” with different sections for procedures, medications, therapies, encounters, diagnoses, etc. There is no clinical coherence or correlation between the sections, so providers must search in multiple places to find information relevant to a problem.
Clinicians are highly trained knowledge workers whose expertise in determining what is clinically relevant is acquired through education and experience. They are trained to know what to look for, but current EHRs make it difficult to get a clinically cognitive view of relevant information.
The new kind of EHR advocated by Glaser will require a clinical relevancy engine that can filter a patient record in real time to identify data for any known or suspected condition or diagnosis. This “clinically coherent view” should include medications, lab orders and results, co-morbidities, therapies, symptoms, history, and physical exam findings. Ideally, it should support diagnostic filtering of dictated or free-text notes, as well as coded data such as SNOMED-CT, ICD10, CPT, LOINC, RxNorm, UNII, CVX, CTCAE, DSM5, and others.
It must do so quickly, on demand, with a single click at the point of care.
This new cognitive clinical computing approach requires a radically different method for organizing clinical data. First, data must be organized to support a clinician’s diagnostic thought process. Second, because of the need to process hundreds of thousands of potentially relevant data points and the relationships between them in sub-second times, graph database technologies must be used. Relational databases cannot provide the computational efficiency that is required to support highly trained clinical knowledge workers.
A clinical relevancy engine that is organized around clinical conditions or diagnoses will have millions of potential links between diagnoses and related clinical data points. Relational databases that join tables together were not designed to support data structures with millions of interconnected nodes. Graph database technologies, which are used for complex, connected data, are used by Amazon, Facebook, Google, and others to support large, evolving data structures.
A purpose-built clinical relevancy engine that uses graph database technology will support the clinical thought process by linking clinical concepts (or “nodes”) to each other, with relevancy scoring that enhances clinical decision-making and integrates with systems to maximize physician workflows. This engine enables a clinical user to get an instantaneous view of all information related to any patient presentation in a single view, incorporating both coded data and data points derived from chart notes by using diagnostic natural language processing (NLP) applied to free-text notes.
The old ways of building EHRs to support tracking of transactions for billing will not suffice in the world of value-based care, clinical risk mitigation, and outcomes-oriented reimbursement. Glaser’s proposed new kind of electronic health record must be built on a foundation of clinical intelligence.
Re: The old ways of building EHRs to support tracking of transactions for billing will not suffice…
If I have heard this once I have heard it a million times, and it is wrong, wrong, and wrong again. Yes it was true in 1960 thru 1980, but all of the leading EHRs of today (Cerner, Epic and Meditech) were first designed for clinical environments not financial transactions. In fact, Epic’s financial system was one of it’s last major developments, and Cerner even today does not have a decent financial system, they had to buy Siemens (SMS) to get one.
So if there is a problem with the design of today’s EHR it has nothing to do with transactions. Yet I do agree that relational data bases are not well suited for medical research or care management. Which is why MUMPS was created back in the last century!
While I do agree that the current EHR schemas are not the best at categorization or enabling clinical decision making, I would challenge the idea that simply slipping to graph database technologies will be sufficient to solve the problems inherent in today’s EHR.
If you have examples of NLP that is working in clinical notes I would be happy to change my views on the state of the art in clinical NLP. Proofs to date have not been fruitful and with the use of boilerplates, scribes, and other ‘efficiency’ solutions, I am afraid you would do nothing but make a low IQ AI. If I recall correctly, this was part of the problem with the Watson health solution — that and ‘manufactured’ training of course.
I do see how graph technologies would be highly useful to the clinical research community. Especially if we are talking about syndromic surveillance and population health activities. However, that is yet another interoperability challenge — specifically making different schemas, models, and purposes work together for their intended purpose.
As a young CI agent, I used to have to build these connection graphs from scratch — they can be highly valuable, but they do require a level of data validation that I am afraid would be a challenge for todays EHR data, and you can’t get to clinical intelligence except through the data and information.
I do agree that John Glaser is onto where we need to go, and perhaps you are working to a solution that would meet these needs. Bravo if true, but we have to acknowledge that there are reasons for the multitude of solutions that are using very similar structures. As well, we need to recognize that our systems are built for the payers. We can’t disconnect those facts.
Thanks for the article
Sure, graph databases are hip. But how does reformulating a proprietary clinical vocabulary as a graph database solve the problem of semantic interoperability?
The concepts in the graph database need to be mapped to the relevant vocabularies and code sets for the different domains: ICD10, CPT, SNOMED CT, LOINC, RxNorm, CVX, UNII, DSM5, etc. The graph database is used for the clinical relevancy links, of which there are hundreds of millions, while mappings to the various clinical vocabularies, of which there are less than two million, are maintained independently but available through APIs.