Home » Readers Write » Currently Reading:

Readers Write: Enabling Clinically Intelligent EHRs

July 6, 2020 Readers Write 4 Comments

Enabling Clinically Intelligent EHRs
By David Lareau

David Lareau is CEO of Medicomp Systems of Chantilly, VA.

image

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.



HIStalk Featured Sponsors

     

Currently there are "4 comments" on this Article:

  1. 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!

  2. 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

  3. 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.







Text Ads


RECENT COMMENTS

  1. I think Disingenuous is confused (or simply not aware of how it has been architected). How control of Epic is…

  2. It seems that every innovation in the past 50 years has claimed that it would save money and lives. There…

  3. Well, this is predicting the future, and my crystal ball is cloudy and cracked. But my basic thesis about Meditech?…

  4. RE Judy Faulkner's foundation wishes: Different area, but read up on the Barnes Foundation to see how things work out…

  5. Meditech certainly benefited from Cerner and Allscripts stumbles and before that the failures of ECW and Athena’s inpatient expansions. I…

Founding Sponsors


 

Platinum Sponsors


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Gold Sponsors


 

 

 

 

 

 

 

 

 

 

RSS Webinars

  • An error has occurred, which probably means the feed is down. Try again later.