IHTSDO Implementation SIG 10/27/2014 Moon Hee Lee, Principal Silicon Valley Terminology Consulting, USA SNOMED use in the U.S.– examining two organizations

Agenda: Examine the use of SNOMED CT in Kaiser Permanente and UCSF (University of California at San Francisco) Examine the mapping differences between the two organizations Examine how the two organizations approach “gaps” in SNOMED Examine the implications of each method Food for thought

SNOMED Use at Kaiser Permanente (KP) (1) SNOMED is not directly used in EMR KP has an Enterprise Terminology System called “Convergent Medical Terminology” (CMT) CMT is based on SNOMED content and structure CMT team creates SNOMED derivatives and imports into the EMR. They are: Mapping of local (interface) terms to SNOMED and imported into EMR Mapping of local (interface) terms to SNOMED extensions and imported into EMR Local term Subsets created using CMT tool, and imported into EMR

SNOMED Use at Kaiser Permanente (KP) (2) KP as an organization is one of the oldest users of SNOMED Still, main users of SNOMED are the CMT modelers CMT Team continues to evangelize and educate KP community regarding SNOMED by making tools that can be easily adopted by them (to enable advanced querying by SNOMED attribute value pairs)

SNOMED Use at UCSF Academic and Research institution New to SNOMED Only begun to use SNOMED because it is required by Meaningful Use (Incentive program to use certified EHR technology in the U.S.) Diagnosis and Problem List terminology content and SNOMED mapping is provided by 3 rd party vendor SNOMED hierarchy and mapping is directly used in EMR to create subsets (but limited to hierarchical relationships) Research/Analytics team is just beginning to learn of SNOMED and not sure how to use/leverage it

SNOMED Use and Adoption in the U.S. – my observations thus far Kaiser Permanente is atypical Much of SNOMED use is limited to mapping local terms to SNOMED to meet Meaningful Use requirements When SNOMED is used for subset/refset creation, usually limited to hierarchical relationships, and not subsumption based queries Sophisticated knowledge and tool is required to use and adopt SNOMED description logic, which is still a barrier for many organizations, large and small

Examining Mapping Differences Background: Both Kaiser Permanente and UCSF use same EMR vendor Kaiser Permanente uses CMT, Kaiser’s enterprise terminology system UCSF uses third party vendor for Diagnosis and Problem List Terminology This vendor associates “map quality” with each mappings: “exact”, “narrower than”, “broader than” KP mapping is always exact, or one to one This section of the presentation focuses on Problem List terminology

Mapping differences (1) UCSF: KP:

Mapping differences (2) UCSF: KP:

Implications of Mapping differences For interoperability? Receiving organization can potentially have 3 different ways a same concept is represented - theirs, KP’s, UCSF’s, for example For ICD-11? Local terms that are conceptually the same could end up with different ICD-11 mapping if derived from its SNOMED mappings Anything else?

Approaches for handling “gap” in SNOMED “Loose” mapping – narrower than, broader than Create Local extensions – one to one/exact Note: “local extensions” – organization-specific extension, not member country extension Omission

Loose map vs Local extension (1): UCSF: local term is “narrower than” SNOMED KP: local term is mapped to local extension

Loose map vs Local extension (1): UCSF: local term is “narrower than” SNOMED KP: local term is mapped to local extension Local extension

Implications of various approaches of “gap” handling – “loose” mapping Can file automatically in the receiving System, but will lose the specificity “map quality” should also be sent and be understood by the receiving system Can be included in subset creation because it is mapped to SNOMED, but need to define the query at higher up in the hierarchy to be able to retrieve local terms since local terms are narrower

Implications of various approaches of “gap” handling – local extensions Won’t file automatically in the receiving System since SNOMED IDs won’t be automatically understood Will invite human intervention May not benefit from SNOMED-ICD11 work, since local extension not represented in SNOMED Core

Implications of various approaches of “gap” handling – omission (not mapping) Won’t file automatically in the receiving System since there is no mapping Will invite human intervention Will not get included in subset creation based on SNOMED relationship alone. Subset tools need to be capable of pulling it in by other characteristics, i.e. “ICD code”

Food for thought: Although SNOMED has been available for many years, it is not until just recently that SNOMED has been adopted nationally in the U.S. “Adoption” still mostly limited to mapping, but mapping seems heterogeneous across organizations, sometimes even within same organization, in the U.S. What can be done to decrease heterogeneity? What can be done to use SNOMED to its full extent, beyond mapping alone?