Home » Readers Write » Currently Reading:

Readers Write: The Case for One Source of Truth

June 26, 2013 Readers Write 4 Comments

The Case for One Source of Truth
By Deborah Kohn

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.

clip_image002

© Deborah Kohn 2013

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


Deborah Kohn, MPH, RHIA, FACHE, CPHIMS, CIP is a principal with
Dak Systems Consulting.



HIStalk Featured Sponsors

     

Currently there are "4 comments" on this Article:

  1. howdy Deborah

    Although SNOMED isn’t the monolothic CAP that you outline, I believe that’s its intended goal. SNOMED covers quite a bit, spanning drugs, problems, labs, and a few other areas.

    You probably know more about this than I do, so I’m sure I’m missing something

  2. Hi Kyle:

    You are correct that SNOMED CT (and ICD-11) is moving to cover a more broad range of clinical terminology. However, today it does not cover all use cases, as I pointed out. It will be most interesting to watch how ALL the clinical classification systems (used primarily for reimbursement) and ALL the clinical terminology systems (used primarily for patient care) evolve, and, as rumor has it, perhaps, one day, even converge. Should that ultimately occur, during the long interim (as you know, it takes YEARS to update, develop, and publish these systems, let alone converge), a CAP will be needed! Thanks for your important feedback.

  3. Thank you for this excellent article. It’s kind of like “middleware” that will enable disparate systems to serve the needs of patients, providers, staff, payers, and researchers. Having worked in hospitals, home care, long term, and ambulatory care, I am all too familiar with the dyslexia that exists in the languages of their systems. The CAP is a next-generation solution. By the way, NCQA just announced the inclusion of Value Sets in the 2014 Healthcare Effectiveness Data and Information Set (HEDIS) program, as a way to transition to ICD-10 in 2015.

  4. Hi BigNurse:

    Yup! A CAP is “middleware” — enabling disparate terminology and classification systems to serve the needs of all healthcare users and use cases. Thanks for the NCQA update and your feedback!







Text Ads


RECENT COMMENTS

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

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

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

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

  5. Yes, Meditech will talk your ears off about Expanse. There are multiple factors at play here which undercut both Meditech…

Founding Sponsors


 

Platinum Sponsors


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Gold Sponsors