If you know a little bit about Symedical, you are probably aware that it is world-class software tooling that supports healthcare data quality efforts. Did you know that Clinical Architecture is also cooking up clinically curated content built on top of these industry standard terminologies to complement your software investment? There are two types of content that complement the underlying architecture of Symedical.
The first type of content is called a Clinical View Model. This is content that enables a user to intelligently filter large sets of patient data. This can be helpful when a user is overloaded with information in an EHR or HIE, as the intersection of Clinical View Model content with patient data brings important and relevant data into focus. For example, a diabetes Clinical View Model might highlight hemoglobin A1c results, oral antihyperglycemic agents, and other related labs, medications, complications, etc.
Sample diabetes Clinical View Model.
We offer Clinical View Models to address all of the CMS chronic conditions that account for the highest prevalence, utilization, and burden to the U.S. health care system. Additional Clinical View Models have been prioritized based on the National Ambulatory Medical Care Survey, AHRQ Multiple Chronic Conditions Chartbook, and other sources.
The second type is Inference content that uses rules-based logical reasoning to provide insights into structured patient data. Such rules-based content may be applied toward:
- Detecting undocumented conditions (e.g., COPD, diabetes, heart failure, hypertension)
- Maximizing reimbursement (e.g., CMS national coverage determination criteria)
- Identifying at-risk individuals (e.g., VTE, postoperative bleeding, opioid overutilization)
- Submitting reportable conditions to state agencies (e.g., pertussis)
- Capturing cohorts (e.g., patients with multiple readmissions)
- Avoiding unnecessary care (e.g., vitamin D screening, myoglobin/CK-MB in ACS)
- Pharmacogenomic-based dosing (e.g., clopidogrel metabolism and CYP2C19 gene mutation)
- Calculating scores (e.g., Pneumonia Severity Index, morphine milligram equivalents)
- Ensuring patient safety (e.g., Opioid prescribing, Beers criteria)
Sample Inference response following detection of undocumented diabetes.
While Inferences can be made accessible at the point of care, we recognize that physicians can be overloaded with too many alerts. Therefore, our Inference content is designed to add value to the broader health system’s value-based care initiatives which are in part focused on systems-level care efficiency and the health and well-being of populations.
Let’s take a tour through the proverbial kitchen where we create this content. There are 3 main steps.
Step 1: Plan. A chef might perform research to generate new ideas, decide what type of cuisine to cook, and gather recipes. In a similar fashion, content creation involves planning. This includes identification of the most reputable sources of clinical information such as guidelines from national and professional organizations. One must also assess what kinds of clinical recommendations can be modeled—for example, if an action is dependent on knowing a patient’s left ventricular ejection fraction or postbronchodilator FEV1/FVC, can we expect to find that information in structured patient data? By the way, I previously described how we can.
Step 2: Organize. Before cooking, a chef must obtain ingredients and prepare them by peeling, dicing, grating, etc. A similar activity must be performed before creating Clinical View Models and Inferences. This process begins with subscribing to the relevant standard reference terminologies and mapping local terminologies to those reference terms to ensure alignment with patient instance data. With these ingredients, we can then create “elements” which are clinical concepts (e.g., type 2 diabetes mellitus) that are given meaning by binding them to standard reference terminologies (e.g., ICD-10-CM code E11 and all of its descendants). Elements can represent conditions (using ICD-10-CM, SNOMED CT, and other sources), medications (using RxNorm), labs (using LOINC), allergies (using NDF-RT and MED-RT), and other domains of clinical patient information.
Step 3: Create. The final step in cooking is to put all the ingredients together and then bake, grill, fry, etc. Similarly, the organization of elements allows us to configure them in meaningful ways.
A Clinical View Model is simply an ontology (a set of concepts and the relationships between them) that is created by connecting one element to another through a defined set of relationships. For example, the “type 2 diabetes mellitus” element has the following relationships to other elements:
- Measured By: hemoglobin A1c, lipids, etc.
- Treated By: biguanides, sulfonylureas, insulins, etc.
- Has Complication: diabetic retinopathy, diabetic neuropathy, etc.
Inferences also leverage elements as a basic building block. When elements are used in logic expressions, we can easily determine things such as:
- Is diabetes absent from the problem list?
- Is there evidence of diabetes?
- Is the latest hemoglobin A1c greater than a certain numeric threshold?
- Is the patient being treated with antidiabetic agents?
If conditions 1 and 2 are true, then an action might be triggered to consider documentation of undocumented diabetes as depicted above. These determinations are all made possible by comparing patient instance data (mapped to standard terminologies) with elements (represented by standard terminologies) and their relationships or logic criteria.
While cooking with terminologies can be fun, we understand that being a “terminology master chef” is not for everyone. For individuals who would prefer a meal kit delivery option (customized and seasoned to taste) or just to feast on all the benefits of Clinical View Models and Inferences (used out of the box), we support those options too. Let us know if you’re hungry.