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.

Accent on Objects

It has been many years since I acknowledged patient record subpoenas for medical malpractice lawsuits and other legal actions as an HIM professional and designated custodian of records (COR). But the process was memorable.

During the 1970s, one was not able to reproduce analog paper and photographic film or send records by postal mail or courier to the courts.  Rudimentary paper and film photocopy machines only recently were introduced into healthcare organizations, and the courts required the personal delivery of “original” source documents and records by a COR.  Consequently, upon receiving patient record subpoenas, I took a large cardboard box and collected from each department the “original” source documents required by the subpoenas. The contents included the patient’s paper financial and medical records.  The medical records also included all film-based diagnostic images, tape-based medical dictation, cine-based ECGs, and pathology slides.

During the 1980s, when I established my related career in HIT and because of my COR experiences during the “analog” years, I knew well that electronic patient records consisted of more than just the structured data typically found in electronic patient financial and medical records. (Structured data are the record’s binary, discrete, and computer-readable data elements that, typically, are stored in relational databases with predefined fields.)  Electronic medical records (EMRs) also consisted of digital diagnostic images, audio file-based dictation, and ECG waveforms. In fact, such unstructured data make up at least 75% of all the data in a typical patient’s EMR.  (Unstructured data are the record’s non-binary, non-discrete, and often human-readable data elements that, typically, are contained in text-based reports, emails, and web pages and include symbols, images, video clips and audio clips.  In some vertical markets, unstructured data are referred to as a record’s intellectual substance or content.  In technical arenas, unstructured data are referred to as “objects”.)

Just like healthcare organizations, the courts finally have entered the digital age. Today, secured electronic files of “original,” electronic source documents and records as well as “copies” of original, electronic source documents and records are admissible in courts as long as the healthcare organization can substantiate (1) the trustworthiness of the system(s) used to store and retrieve the documents and records; (2) the accuracy of the organization’s records management policies and procedures; and (3) the documents and records were not created (or altered!) just for a court case. (NOTE:  Always one must verify the courts’ acceptance of digital records on a state-by-state basis.)

Large cardboard boxes have been replaced by EMR (or other system) features that promote single points of personalized access through which to find and deliver electronic information, applications, and services. As such, in either hybrid or full EMR environments, designated CORs, Release of Information professionals, and even patients—after rigorous authorization and authentication processes—merely click on hyperlinks and instantaneously retrieve “original” electronic source documents and records required by subpoenas or other requesters.

While our industry continues to pursue the best “highways” to securely transmit the documents to and acknowledge receipt from requesters, today’s day-to-day challenges involve the current mechanisms used to transmit unstructured data and the shameful output of structured data generated by most EMR systems.

For example, the transmission of the large and ever-growing number of patient diagnostic images (primarily radiology images), which remain hand-carried or sent by postal mail or courier from hospitals, physicians / groups, specialty (e.g., cancer) centers, etc., to other hospitals, physicians / groups, and specialty centers on CD storage media, is completely unmanageable. Many of the CDs containing (e.g., radiology) diagnostic images cannot be imported into the receiving Radiology PACS due to the way the images were burned into the CDs.  Although most of the CDs include the senders’ viewers for measuring, window / leveling, etc., often the CD files arrive corrupted.  Frequently the CDs are misfiled and / or lost.  Consequently, transmitting diagnostic images on CDs has lead to duplicate testing with more patient exposure to radiation.  In addition, when the CDs contain diagnostic images other than radiology images, often the receivers have no corresponding PACS for these other, “ology” images.

Thankfully, popular, standard, inbound (i.e., CD ingestion and electronic receipt of diagnostic images) and outbound (i.e., report and image distribution to referring physicians, referral centers, etc.) image sharing solutions exist.  However, most are too expensive for the healthcare provider masses.  In addition, few, if any, non-standard image sharing solutions exist, whereby direct connections are established between two or more organizations for readings, consultations, and 2nd opinions and inbound and outbound electronic reports accompany the images.

Also, there is not a healthcare professional that has not experienced the reams of paper output generated by EMR systems because the systems’ structured data are not report-formatted for output. This is one reason why a patient still cannot receive his/her entire patient record from a portal!  Not that I promote hard copy printing; however, healthcare providers still must maintain a legal archive from which to generate the electronic document presentation as proof for exception and dispute handling.  In other words, providers must have the document presentation for legal purposes and NOT an informational statement or data representation of the document, which, unfortunately, remains common in today’s electronic patient record system output.