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.
I appreciate the information you have shared via this blog. Your insights on school health IT are fascinating, and I…