I have a great idea on how we could reduce healthcare costs. We reduce the number of doctors we need by installing Automated Drug Machines or “ADMs” in our clinics. For example, you could go to the machine and enter your Medical Record Number and your complaint – chest pain. The helpful ADM would ask your age, 42, and would use statistics to determine that you have a case of heartburn and would dispense an antacid and debit your checking account. On the way home, you have a major heart attack and …
Compare this to what really happens. You call for an appointment with your doctor and when you arrive, she asks question after question, reviews her notes from recent visits, and looks at the corresponding labs to quickly determine that given your family history and your lab values, you are about to have a heart attack.
Unlike other industries such as banking, healthcare will archive some of its most important clinical data in large textual notes such as progress notes, visit summaries, etc.. In fact, a search for a salient clinical datum point is, practically speaking, more similar to conducting a term-search on the Internet using Google. However, unlike a web search, it is important that we correlate the located notes with valid clinical data such as labs. Therefore, we must be able to efficiently query and display data from both structured data (labs) with semi-structured data (notes) to present a clear clinical picture.
Fortunately, database technologies today allow us to query and search from the same database platform. Full-Text-Search (“FTS”) will index a column of data and allow us to join results with standard SQL query results.
Microsoft SQL Server has supported FTS for several years now; and, most other relational database products, including MySQL, support this technology. Therefore, it is important for us in the clinical reporting arena to offer both solutions to our clinicians.
The following are some features that Microsoft SQL Server provides to help us find and display clinical terms:
- SQL can index text documents and automatically do Optical Character Recognition (“OCR”) on things such as PDF or TIFF documents. Once configured, it just works.
- It is blazingly fast. As an example, I created at our hospital an Entity-Attribute-Value (“EAV”) database for all of our HL7 feeds so we could validate Amalga parsing. The “value” column holds both structured and semi-structured (notes) data spread over about 3 billion records and I can use FTS to find a word or phrase in seconds.
- SQL supports a custom medical thesaurus so that a search for EKG would return both EKG and ECG found in the records.
- We can use “prefixed searches” where a search for hyper* would return records with hyperactive and hypertensive.
- It is easy to correlate FTS records with typical analytical data in the same query. So we can now implement a query that will get the results for: “show me Bruce’s lab values for cholesterol for the year proceeding any encounter where he complained of chest pain”.
Given how mature the FTS technology as become, and how pervasive it is across the different database platforms, there is no reason not to include it in clinical analytics.
However, wouldn’t it be great if we could also add some additional functionality such as applying metadata tags (data about the data) and to be able to include those in our search. In my next post, I will discuss how the new SharePoint with Search can be used in healthcare to provide even more accurate searches.