The Case for One Source of Truth

The notion of managing and being accountable for the health status of defined populations requires much more sophisticated clinical data collection methods and skills than most healthcare organizations have today.  However, for decades, numerous coded systems have been used to successfully capture clinical data for reporting purposes, such as quality initiatives and outcome measurements, as well as for reimbursement and other, myriad purposes.


Such coded systems, which health information professionals categorize as either clinical classification systems[1] or clinical terminology systems[2], can continue to be used to assist in determining prospective, pre-emptive care management on covered populations.  However, no single classification system meets all use cases.  ICD-9 CM does not contain medications.  ICD-10 CM does not address functional status.  In addition, no single terminology system meets all use cases.  LOINC is used to encode laboratory data.  SNOMED CT is used to encode clinical care data.  RxNorm is used to encode medications.


Consequently, using the existing or newer coded systems to meet any of the fast-growing, clinical data collection and analysis initiatives presents a significant challenge:  too many systems from which to choose, hindering any efforts to change the collection of the data into actionable information for interoperability and health information exchange.  To resolve this challenge, one “one source of truth” or one central authority platform (CAP) for all clinical data capture systems, existing and new, allows all coded systems to be used to capture and exchange information.


With one CAP, healthcare organizations need not be concerned about when to use which data collection system for which purpose.  Organizations are able to capture required clinical, financial and administrative data once and use it many times, such as for adjudication and information governance purposes.  In addition, organizations are able to compare the data for data integrity purposes.  More importantly, organizations are assured that electronic healthcare data input by different users is semantically interoperable – i.e., that the data are understood and used while the original meaning of the data is maintained.


For example, for typical diabetic patients, Reference Lab #1 might denote glycohemoglobin within the chemistry panel, Physician Office Lab #2 might denote glycohemoglobin as an independent test: HgbA1c, and Hospital Lab #3 might use the embedded LOINC code: 4548-4.  The central authority platform recognizes each of the three laboratory information system inputs representing the same value — glucose level.  Subsequently, the healthcare organization’s electronic health record (EHR) or business intelligence system makes use of the common meaning and, for example, generates a trend analysis of the patient’s glucose readings over time.


Developing a CAP requires considerable effort.  The platform must be able to store all coded values, metadata, and all the content / terms.  It must be able to normalize and catalog all the content / terms.  It must be able track all changes in content identifiers, watches for differences in terms, cross-maps the content, route the content while preserving the data and context, and regenerate the data and content as it was stored.  Finally, it must be able to manage all the content updates / releases.  Today both the public and private domains have been moderately successful in developing the platform.


The Office of the National Coordinator for Health Information Technology (ONC) and the Centers for Medicare & Medicaid Services (CMS) collaborated with the National Library of Medicine (NLM) to provide the Value Set Authority Center (VSAC).  VSAC is to become the public domain, central authority platform for the official versions of the value sets that support Meaningful Use’s 2014 Clinical Quality Measures (CQMs).  However, currently VSAC does not go far enough to cover all use cases.


In the private domain, several health information technology vendors provide most of the required capabilities of the CAP.  Interestingly, these vendors collaborated with clinical professionals to create different categories of coded systems to describe their products than those categories created decades ago by health information professionals.  For example, the vendors refer to any coded system used for capturing and exchanging data as a “terminology” system, even though some of these systems are categorized by health information professionals as classification systems.  In addition, the vendors categorize all “terminologies” as either standard[3] or local terminologies[4].  Some of these vendors go even farther in categorizing all “terminologies” as either retrospective or point-of-care terminologies[5].  Consequently, today not only are there too many coded systems for data capture and exchange from which to choose, but too many categories of coded systems to make sense of it all.


Assuming that both public and private domain CAP options will prevail, healthcare organizations can expect widespread use of the platforms, allowing EHRs and other electronic records, such as financial records, to incorporate multiple coded systems for specified needs.  In addition, workforce demands for the clinical informatics skills needed to manage all the coded data will continue to remain strong.



[1] Clinical classification systems, such as ICD-9-CM, ICD-10-CM, and ICD-10-PCS derive from epidemiology and health information management.  These systems group similar diseases and procedures based on predetermined categories for body systems, etiology or life phases.  As such, they organize related entities for easy retrieval.  They are considered “output” rather than “input” systems and were never intended or designed for the primary documentation (or input) of clinical care.


[2] Clinical terminology systems (a.k.a., nomenclature or vocabulary systems), such as SNOMED CT and RxNorm derive from health informatics.  These systems are expressed in “natural” language, and, typically, codify the clinical information captured in an electronic health record (EHR) during the course of patient care (because the number of items and level of detail cannot be effectively managed without automation).  As such, they are considered “input” systems.


[3] Standard terminologies consist of “administrative” terminologies, such as ICD and CPT, and “reference” terminologies, such as SNOMED, LOINC, RxNorm, and UMLS.


[4] Local terminologies are those that healthcare providers, such as laboratories or physicians, use on a daily basis in their records, on the telephone, etc., to describe specific diagnoses and procedures.


[5] Retrospective terminologies consist of all standard terminologies (administrative and reference) and local terminologies, while point-of-care terminologies are those that are healthcare provider-friendly and used for specific documents.