How Solor is Different from Mapping
What Is Clinical Data Mapping?
Today, healthcare systems do not represent their clinical data in the same way. Clinical data mapping tries to overcome this data incompatibility by correlating meanings between healthcare systems (for example, names of procedures or medicines and/or codes for billing purposes) using a broader than-, narrower than-, or equivalent to- mapping table. Healthcare systems then use this mapping table as a primitive means to achieve data interoperability (the ability to preserve the meaning of clinical information shared between systems). Interoperability is necessary to coordinate care between healthcare systems and to utilize clinical decision support based on complete information.
Why Do Healthcare Systems Use Data Mapping?
Healthcare systems create mapping to exchange administrative data (sharing data for billing and reporting purposes) and clinical data (sharing health data for individuals who receive health care from more than one health system or facility). To care for patients with “complete” information, providers need the integration of health data from multiple sources. Access to a patient’s complete health record prevents erroneous clinical decisions based on incomplete or inaccurate information.
Mapping is an approach to share data; unfortunately, mapping at each step in the data exchange process creates additional opportunities for error and for loss of information that may lead to a patient’s harm. SNOMED CT and other meaningful use standards are frequently used as targets of this mapping, and their use is mandated as part of the Meaningful Use regulations. Tables 1 and 2 below show how equivalent concepts in two different care settings leads to information loss when they are mapped to SNOMED CT because SNOMED CT does not represent the equivalent meaning. In Table 1 and 2, the Local Concept column represents the concept created by Hospital A during the care of a patient, the Map Type column specifies broader than or narrower than or equivalent, and the SNOMED CT Concept column represents the concept to which the local concept has been mapped. The Meaning Lost column describes the information lost due to mapping because an equivalent match of the local concept is not found in SNOMED CT. In the first Table below, the SNOMED CT Concept is broader than the local concept causing important tumor morphology information to be lost during mapping. In Table 2, the SNOMED CT Concept is also a broader than the local concept causing important tumor location information to be lost in the mapping process.
Table 1: Hospital A Mapping Example
Table 2: Medical Practice Mapping Example
How Is Solor Different?
Rather than correlating through a broader than-, narrower-than or equivalent-to mapping table, Solor is a platform that integrates clinical terminologies, such as SNOMED CT, LOINC, and RxNorm, in a way that enhances their collective use in healthcare applications and keeps the health information exchanged completely intact. Solor facilitates this integration by transforming these disparate systems into a single common model. With only one model to support instead of many, Solor is easier to use, and further provides extension capabilities regarding how clinical data is represented. By protecting the original clinical meaning behind these terminologies, the Solor common model will better support healthcare interoperability, and reduce the possibility of information loss and patient harm.
To ensure clinical data exchange without loss of information, Solor enables the extension of standards in ways that allow providers and consumers of data to preserve the equivalent meaning of the clinical content. Tables 3 – 5 show how the information-sharing challenge presented in Tables 1 and 2 can leverage the Solor extension model to exchange the same clinical data with no information loss.
Table 3: Hospital A Mapping Example, with locally created Solor extension concept. *The mapping type in this example is NA because in Solor there is no mapping, new concepts are created instead.
Table 4: Incorporation of a new concept into Hospital A’s Solor extension
In Table 3, Hospital A has extended the Solor terminology content by introducing a new concept that is semantically equivalent to its local concept, and incorporating the new concept into the Solor concept hierarchy in a manner consistent with the Solor common model. The result, shown in Table 4, is the correct classification of the concept with respect to existing concepts within the SNOMED-CT, LOINC, and RxNorm standard terminologies. Hospital A can also share its Solor extensions, allowing it to use standards-compatible codes that are more granular than what may currently be in a standard. Further, by sharing the codes in its Solor extension with other organizations, Hospital A has a means to share its data with no information loss.
Specifically, as illustrated in Figure 1 and Table 5 below, Medical Practice looks in that shared extension for an equivalent meaning to its own local concept before adding new content, identifies the existing extension code created by Hospital A, and uses that code to map the Solor terminology to its local code. By this process, Medical Practice can receive equivalent clinical data from Hospital A with no information loss whatsoever, an outcome not possible if Hospital A and Medical Practice were limited to simple narrower-than, broader-than, and equivalent-to mappings to standard terminologies.
Figure 1: Shared Solor Extension
Table 5: Medical Practice Mapping Example, leveraging the extension content of Hospital A
Lastly, note that if Medical Practice’s local code were equivalent to one of the existing SNOMED-CT codes (for example, “SCTID 408643008 – Infiltrating duct carcinoma of breast (disorder)” ), the Solor terminology model would not only indicate that the code received from Hospital A was more specific than the local code, but would also precisely represent the semantic distinction between the codes (i.e., that the received code identified the anatomical location of the disorder more specifically). This information could be critical in determining whether any automated inferences with respect to the local code (for example, in decision-support rules or clinical quality measures) would also hold with respect to the received code. Again, such information would not be available if Hospital A and Medical Practice were limited to narrower-than, broader-than, and equivalent-to mappings to standard terminologies.
Want to Learn More?
To learn more about how Solor works, find more information in our Solor white paper: “Achieving Semantic Data Interoperability.” You can also download the Solor Viewer with the accompanying user guide. After installing the Viewer, you can navigate Solor content, search Solor content, and view Solor details of the data elements. Be sure to follow Solor on Twitter to stay up to date on the latest Solor news!
Recent Comments