The EMR as a Data Shredder: Implications of a Single-Source-of-Truth Policy

My colleague in pathology at the University of Michigan, Dr. Ulysses Balis, has taken to referring to EMRs as data shredders. What does he mean by this? The use of the term simply reflects that fact that after an LIS transmits test results to an EMR as an HL7 stream, they are reformatted based on the rules and constraints of the EMR system. The sad part about this daily scenario is that pathologists and lab medicine experts have been perfecting lab result formatting for many decades and the EMR support personnel frequently have little or no understanding about this knowledge domain. They thus turn to lab professionals for help in formatting the data that had been optimized in the LIS prior to transmission but which were then shredded by the interface and the EMR.

Lab data formatting is an integral and critical element of any lab report. Let's use the term of truthfulness to describe the degree of quality, accuracy, and interpretability that is sought in the development of a lab report. Or, for Stephen Colbert fans, one can also use the term truthiness. Lab test results that has been shredded are therefore less truthful. The best way to maintain the truthfulness of test results generated and transmitted from the LIS to "whatever" system is to replicate a true copy of them to the other system. In other words, the LIS needs to be viewed as a single-source-of-truth (SSOT).

Here's the Wikipedia definition for SSOT with boldface emphasis mine:

In information systems, Single Source Of Truth (SSOT) refers to the practice of co-locating in one area only (e.g. one cell of one row of one table of one database) any data that can be referred to by any of the other federated applications present within the overall enterprise. Deployment of this architecture is becoming increasingly important in enterprise settings where incorrectly linked duplicate or denormalized data (a direct consequence of intentional or unintentional denormalization of the data model) poses a risk for retrieval of outdated, and therefore, incorrect information. A common example would be the electronic health record, where it is imperative to accurately identify patient identity against a single referential repository, which acts as the SSOT. Duplicate representations of data within the enterprise would be implemented by the use of pointers rather than duplicate database tables, rows or cells. This ensures that data updates to the authoritative location are comprehensively distributed to all federated database constituencies of the larger overall enterprise architecture. SSOT systems provide data that are authentic, relevant and referable.

In order to achieve SSOT status for the LIS and other sources of clinical information, hospitals need to pursue a federated information system architecture. The practicality and feasibility of this model/architecture for healthcare is only now becoming apparent and has certainly not been utilized by any EMR in widespread usage. There is therefore only one course of action for lab professionals trying to cope with an EMR shredder problem. For relatively simple test results passed to the EMR, they need to collaborate with the EMR support personnel to renormalize the data post-shredding. For complex results such as molecular diagnostics, they need to insist that lab customers log on to the LIS for reporting purposes or have access to an image of the report. Finally, they need to actively lobby for the development of a federated architecture that enables the so-called "ancillary" information systems to function as SSOTs.

:: Update on 10/1/2008 @ 11:15 a.m.

There is an updated definition of single-source-of-truth (SSOT) posted on the Wikipedia, which I reproduce below:

In Information Systems Design and theory, as instantiated at the Enterprise Level, Single Source Of Truth (SSOT) refers to the practice of structuring information models and associated schemata, such that every data element is stored exactly once and no more (e.g. in no more than a single row of a single table). Any possible linkages to this data element (possibly in other areas of the relational schema or even in distant federated databases) are by reference only. Thus, when any such data element is updated, this update propagates to the enterprise at large, without the possibility of a duplicate value somewhere in the distant enterprise not being updated (as there would be no duplicate values to update). Deployment of this architecture is becoming increasingly important in enterprise settings where incorrectly-linked duplicate or denormalized data elements (a direct consequence of intentional or unintentional denormalization of any explicit data model) poses a risk for retrieval of outdated, and therefore, incorrect information. A common example would be the electronic health record, where it is imperative to accurately validate patient identity against a single referential repository, which serves as the SSOT. Duplicate representations of data within the enterprise would be implemented by the use of pointers rather than duplicate database tables, rows or cells. This ensures that data updates to elements in the authoritative location are comprehensively distributed to all federated database constituencies in the larger overall enterprise architecture. SSOT systems provide data that are authentic, relevant and referable.

Comments

[Adam Peters]

In the Department of Defense Military Health System (MHS) we deal with the issue of replicate verse single source of truth data constantly. Having the truest information does you no good if it takes all day to get it. There are times (e.g. with trauma cases or when the patient is sitting there and you are already behind by an hour or two) when you need the data or information immediately. So there is a tradeoff here and certainly will be in the future when we look at things like the National Health Information Network. If, as a provider, my system has to query five (or one hundred five in our case) systems every time I bring up a patient to get the full record, then that takes extra time. If every provider's EHRS is doing this it takes time and a lot of bandwidth. Making the provider log into several different systems, to view the best Lab/Rad/Rx data available is also troublesome and IMHO will lead to data being left out of the big picture.
Implementing pointers rather than copies of data is a reasonable workaround, but also presents a tradeoff. Now access to your data may is not only at the mercy of the local network, but the long haul network as well. Many lab tests and many radiologic studies are completed at remote sites, including half-way around the world in India. Now, during downtime at any place in the distributed, SSOT EHRS, the provider may be crippled as they either know that there is a result out there that they can not get to, or, in a poorly designed system, they do not even know that they are missing data so the provider may place a duplicate order, put off a diagnosis until the information is available or misdiagnose based on the missing data.
To sum up, a SSOT system is theoretically the way to go, but the trade-offs must be considered during practical implementation.