Many health practitioners seem to think that interoperability among health systems is the most important issue they face. And that’s almost true. Interoperability is key to keeping real-time operations flowing.
But achieving interoperability doesn’t eliminate a more serious problem: the fact that these systems describe the same situations in completely different ways.
The codes inside our systems are a kind of language that we use to describe, track, and communicate what’s happening in our healthcare organizations. When we try to analyze and understand what’s happening in our organizations, we need to get information from all of our systems and make a coherent picture from it.
Suppose an analyst needs to study a cohort of diabetic men over age 45 who are on blood pressure medications. How would you navigate your systems and the variety of code sets they use to get a list of diabetic patients for her?
Could you further refine your list to include a comorbidity of hypertension?
Consider the following codes:
They all represent diabetes in some state, and come from SNOMED, ICD-9, ICD-10 and NDC respectively. These aren’t the only codes related to diabetes in those code sets, either. Additionally, there are other code sets, such as RxNORM, CPT, LOINC, and others.
To get the information the analyst needs, s/he would need to compile a list of all the related codes needed from all of the related code sets and extract that data from the silos of information systems.
Unless you are versed in each code set or have the ability to crosswalk one code set to the other, harmonizing them into analytic terms that can be leveraged by the enterprise will be very costly and lend itself to untimely and inaccurate information. As a result, you’ll find it difficult to tap into cost take-out opportunities, view a patient holistically and across the continuum of care, and expose opportunities for targeted outreach and market share growth.
Clinical data analysts would be more productive if they didn't have to painfully browse through different clinical vocabularies, terminologies, and code sets in order to compile a list of codes that represent a clinical concept. It would be easier if they could access and plug in value sets comprised of lists of codes and corresponding terms that define clinical concepts such as a category of drugs or a reportable disease.
Consider the earlier example about diabetes codes. If you group together all of the ICD-9, ICD-10, SNOMED-CT, and NDC codes, you can create a value set that indicates patients with diabetes. Healthcare informaticists can leverage these pre-built code groups as building blocks for quality or performance measures or other metrics.
A terminology platform can simplify the above examples, delivering a set of functions to map, manage, mediate, and manipulate terminologies for use and re-use in clinical and analytical applications. A terminology platform can map between standard vocabularies, locally-created content, and standard vocabularies, and between sets of locally-created content. These mappings can support standardized descriptions of clinical findings, patient observations, diagnoses, and interventions, allowing consistently entered information across care settings and by care providers.
One of the many benefits of using a terminology platform is that the burden of maintaining currency in the ever-changing environment is that of the terminology vendor. The terminology layer reflects updates and changes as terminologies and code sets change.
Omni-HealthData, from Information Builders, provides a robust set of reference data management functions. It’s dynamic approach to code sets provides flexibility and respects the varying requirements for storing source codes for transactional and consumption purposes. In addition to code mapping to support harmonization and mastering, Omni-HealthData also stores code sets from source systems as well as those from standard systems such as HL7, ICD-9/10, CPT, HCPCS, and others. It also manages internal custom/legacy code sets created within individual organizations.
Through our progressive and unique partnership with Wolters Kluwer, Omni-HealthData supplies over 1.2 million codes represented within more than 2500 value sets. Industry bodies and internal developers supply these codes and value sets to support HEDIS®, ACO, PQRS, and other measures. Various sources are used to derive the input for the Omni-HealthData code sets, including HL7, FHIR, ANSI, ISO, and CDC. Omni-HealthData develops and delivers HEDIS measures such as cervical cancer screening, lead screening in children, colorectal screening, and more. Examples of ACO measures delivered are diabetes: Hemoglobin A1C Good Control, preventive care and screening: BMI screening and follow up plan, breast cancer screening, Statin Therapy for the Prevention and Treatment of Cardiovascular Disease, and more.
In addition to respecting the individual unique code sets, Omni-HealthData can create crosswalks between code sets to create a sense of similarity in spite of the differences (for example, SNOMED to ICD-9/10, NDC to RxNORM, SNOMED to CPT). Finally, its metadata enrichment capabilities enable the platform to capture an unlimited number of metadata values associated with codes, such as the weights for DRG codes and RVUs for CPT codes that support case mix index calculations.
To find out more about Omni-HealthData and the software that allows provider and payer organizations to acquire, manage, and analyze data more efficiently and effectively, visit our product page.
Note: HEDIS® is a registered trademark of the National Committee for Quality Assurance (NCQA)