# SNOMED/LOINC mapping **Category:** [Implementers (archive)](https://discourse.openehr.org/c/implementers-archive/158) **Created:** 2008-09-29 22:17 UTC **Views:** 7 **Replies:** 5 **URL:** https://discourse.openehr.org/t/snomed-loinc-mapping/14827 --- ## Post #1 by @Greg_Caulton Hi, One of the things that has been holding me up is the conundrum around coded clinical documentation\. I would use OpenEHR exclusively but as I delve into the depths of integration I am getting nervous that the archetypes have not yet been mapped to LOINC or SNOMED\. As an example comparison take a patients \(non\-birth\) weight for example\. In pediatric hospitals and for patients receiving chemo it has always been critical to differentiate between a carefully measured weight suitable to weight dose calculations versus a weight perhaps measured adhoc at an outpatient clinic\. In SNOMED I find 27113001 : body weight \- synonym of Body weight \(observable entity\) In OpenEHR we have openEHR\-EHR\-OBSERVATION\.body\_weight\.v1\.adl which defines the weight, clothing worn, and device used\. In LOINC we have LOINC\_COMPONENT PROPERTY TIME\_ASPCT SYSTEM SCALE\_TYP METHOD\_TYP 3141\-9 Body weight Mass Pt ^Patient Qn Measured 3142\-7 Body weight Mass Pt ^Patient Qn Stated 50064\-5 Body weight Mass Pt ^Patient Qn Ideal 8335\-2 Body weight Mass Pt ^Patient Qn Estimated I expect the SNOMED term could be qualified \- but I would have to search around to figure out with which term would be appropriate \(illustrating the challenge\)\. So I guess ultimately the question boils down to what is everyone/anyone else doing \- OpenEHR \- OpenEHR \+ LOINC \- OpenEHR \+ SNOMED \- All \(tough especially as each system has its own set of terms and concepts of what is what\) And perhaps what does your average EMR doc want? I am not talking about ICD9/10 or CPT codes as I need to do those for billing anyway\. thanks\! Greg http://www.patientos.org Open Source EMR in the making --- ## Post #2 by @thomas.beale Greg Caulton wrote: > > So I guess ultimately the question boils down to what is > everyone/anyone else doing > > \- OpenEHR > \- OpenEHR \+ LOINC > \- OpenEHR \+ SNOMED > \- All \(tough especially as each system has its own set of terms and > concepts of what is what\) > \*the mapping work still largely has to be done; both Snomed and LOINC will be mapped to various archetypes, LOINC obviously more around results\. You could get involved with the effort;\-\) \- thomas --- ## Post #3 by @Greg_Caulton Greg Caulton wrote: >> >> So I guess ultimately the question boils down to what is > > >everyone/anyone else doing >> >> \- OpenEHR >> \- OpenEHR \+ LOINC >> \- OpenEHR \+ SNOMED >> \- All \(tough especially as each system has its own set of terms and >> concepts of what is what\) >> > > > > \*the mapping work still largely has to be done; both Snomed and LOINC > will be mapped to various archetypes, LOINC obviously more around > results\. You could get involved with the effort;\-\) > > \- thomas The problem with SNOMED mapping \(and you wouldn't want me doing that as I would be very bad at it\) is that I assume \(perhaps incorrectly\) that the OpenEHR foundation could not distribute the mapping without the recipients first getting some kind of license for the SNOMED \- not insurmountable but that does complicate things\. I am not sure I fully understand the direction in OpenEHR for lab tests \- creating an archetype per lab test seems overkill but there appear to be some lab test archetypes\. Perhaps OpenEHR should just define 'types' of lab tests and leave the distinct tests to be defined as coded values\. As I discovered with looking at a CCR export LOINC has more than lab tests and so there is definitely overlap \- though it really needs clinicians and a non\-trivial effort\. Likely archetypes would need to be expanded to accommodate everything\. Greg --- ## Post #4 by @mikael Greg Caulton wrote: > The problem with SNOMED mapping \(\[\.\.\.\]\) is that I assume \(perhaps > incorrectly\) that the OpenEHR foundation could not distribute the > mapping without the recipients first getting some kind of license > for the SNOMED \- not insurmountable but that does complicate things\. \[\.\.\.\] A fare as I know there have not been any precedent about what is legal and what is not to do with derivates of SNOMED CT without a license\. But it seems that people involved in IHTSDO’s work think it is ok to handle references to SNOMED CT without a licence\.   Mikael Nyström   Department of Biomedical Engineering   Linköping University   Member of IHTSDO’s technical committee --- ## Post #5 by @heather.leslie Hi Greg, I think that to wait until all archetypes are mapped to terminology reflects losing view of the value that the structured content found in archetypes brings to health informatics\. The structure inherent in an archetype gives an excellent semantic handle on clinical content in the large majority of cases, and the strategic and appropriate mapping of terminology to these archetypes will \(theoretically\) enhance clarity and minimise any potential ambiguity and make the models VERY powerful\. \(Practical experience suggests that this is not as easy as some might think \- and has been alluded to by some others previously\.\) Indeed, there are data points in archetypes that are very dependent on mapping to terminology, such as lists of diagnoses or symptoms \- the free text alternative here is not pretty nor particularly useful for querying\. BUT THESE ARE VERY MUCH IN THE MINORITY, and will often have more of a role in terminology subsets applied in templates\. Archetypes will only have terminology codes incorporated where it is universally applicable \- the archetype by definition is designed as a maximal data set and for a universal usecase, so if there is doubt about the universality of a given terminology code, it probably needs to be applied within a template environment, rather than the archetype\. And remember that Snomed/LOINC is not the only terminology that needs to be incorporated \- there are a lot of places in the world that have no mandated terminology; that do not have a relevant language version of Snomed; that mandate an alternate terminology such as ICD\-10 etc\. So we have a number of terminologies to manage\. The Clinical Knowledge Manager \(CKM \- the openEHR archetype repository\) is being designed from the following point of view \- lets model the clinical content as per clinician requirements in the archetypes, and get them reviewed, published and out there and being used \- as they are increasingly being used in real implementations\! And by all means, let's incorporate terminology as fast and as sensibly as we can\. The reality is that terminology mapping is possibly a slower process than we think, yet one that can happen in parallel or following on from archetype publication\. In the pending CKM, archetypes will be formally regarded as publishable based on agreement on both clinical content and design, by a combination of clinician teams and openEHR geeks\. Terminology mapping can be commenced as soon as the content has been finalised \(otherwise we don't know what content needs a code\), but in the majority of archetypes can safely happen at a later date without major impact on semantic representation of clinical content\. For the minority of archetypes that are identified as having immediate terminology requirements, then this process needs to happen simultaneously\. Similarly, translations can only commence once the content is finalised and published, and will no doubt be an iterative process, with translations being dependant on need\. The CKM is not far away and looking good \- currently undergoing beta testing\.\.\. Will keep you posted\. Cheers Heather Greg Caulton wrote: --- ## Post #6 by @system Hi Greg I am going to take a clinical view in this response. A problem that we have noted is that it is relatively easy to get clinicians to agree about the data that they might want to collect and while structuring it can be a challenge, it is proving tractable. The content from terminologies at various points is a relatively straight forward problem and we have a rapid subsetting tool now that is based on queries against terminologies. Using terminologies to label values (as is used in HL7 v2 and v3) is the domain of LOINC largely, and we have a generic laboratory archetype that allows labels to be coded. This does mean that the queries need to search for LOINC codes as well as the archetypes which is more challenging. Any way, more in line... Greg Caulton wrote: > ``` > Hi, > > One of the things that has been holding me up is the conundrum around > coded clinical documentation. > > ``` It is important to differentiate codes used to label content (LOINC) from the content itself. SNOMED is attempting to do both but it is not clear if it is taking the right approach. > ``` > I would use OpenEHR exclusively but as I delve into the depths of > integration I am getting nervous that the archetypes have not yet been > mapped to LOINC or SNOMED. > > ``` Mapping is complex - as a single code might relate to three or four variables in an archetype (as the code is precoordinated). Average body temperature in the humicrib over 24 hours is an example. LOINC might have a 24hr average, a 10 and an 8 hour as well - separate codes. SNOMED has a syntax for post-coordinating such associated terms : the archetype is a more formal expression of the same thing. > ``` > As an example comparison take a patients (non-birth) weight for > example. In pediatric hospitals and for patients receiving chemo it > has always been critical to differentiate between a carefully measured > weight suitable to weight dose calculations versus a weight perhaps > measured adhoc at an outpatient clinic. > > ``` This would be a protocol statement - perhaps the device would be stated, the precision would be to 3 decimal places and the weight could be labelled 'pre-chemotherapy for dose calculation'. It is still a weight... > ``` > In SNOMED I find > > 27113001 : body weight - synonym of Body weight (observable entity) > > ``` SNOMED struggles through its scope. Any measureable thing of the body can have an 'observable entity', an 'observation of' and a 'procedure to measure'. This is very patchy - one specific problem is that not everything is there as an observable entity. Things like blood pressure have been taken by the terminologists (probably not clinicians) to mean any pressure of blood (central venous, capillary etc) further adding to difficulties. > ``` > In OpenEHR we have > > openEHR-EHR-OBSERVATION.body_weight.v1.adl > > ``` Eric Browne has suggested that we should think about what an archetype records - for that its purpose. ``` openEHR-EHR-OBSERVATION.body_weight.v1.adl RECORDS Body weight (observable entity) It also records information about the state of the person when the measurement was taken - for variables that are deemed important (STATE) and information about the recording (PROTOCOL) - these are patterns in the openEHR archetypes. ``` > ``` > which defines the weight, clothing worn, and device used. > > In LOINC we have > > LOINC_COMPONENT PROPERTY TIME_ASPCT SYSTEM SCALE_TYP METHOD_TYP > 3141-9 Body weight Mass Pt ^Patient Qn Measured > 3142-7 Body weight Mass Pt ^Patient Qn Stated > 50064-5 Body weight Mass Pt ^Patient Qn Ideal > 8335-2 Body weight Mass Pt ^Patient Qn Estimated > > ``` At present the archetype for body weight does not have an idea of estimation - but the value can have the idea of approximatation....clearly it is not appropriate to estimate some things - but body weight is one that people might do. It is common for the foetus for instance. In SNOMED and openEHR a patient can be the information source for any information (this provides the idea of stated). Ideal is perhaps the idea of GOAL - a separate archetype with Targets. But this also relates to the idea of an expected Peak Flow - and we have been discussing adding this idea to the quantity so that we can talk about % of expected. More work to do here. You are going to be useful when we come to do the body weight review! :-) > ``` > I expect the SNOMED term could be qualified - but I would have to > search around to figure out with which term would be appropriate > (illustrating the challenge). > > ``` Yes - it is challenging to get the label codes from SNOMED. > ``` > So I guess ultimately the question boils down to what is > everyone/anyone else doing > > - OpenEHR > - OpenEHR + LOINC > - OpenEHR + SNOMED > - All (tough especially as each system has its own set of terms and > concepts of what is what) > > ``` Well, interoperability only has a chance if we get a foundation on which to build. LOINC will be used for labs in many places and will map to SNOMED at some point in the future. It is needed for HL7 v2 which is the main communication platform at the moment. openEHR is designed to work with multiple terminologies - have a look at the DV_TEXT in the data types model and you will see the mapping class. This does mean that coded terms can be associated with data over time. We have to have a pathway that can bring people along. With archetypes, at least we can lock it down more and more as people see the benefit of semantic interoperability. > ``` > And perhaps what does your average EMR doc want? > > ``` Well, something simple that can be used effectively by a large range of clinicians in different settings. We can agree the archetype relatively easily if we work at it - it does take some time to see how important features of the reference model bring the data forms into alignment. > ``` > I am not talking about ICD9/10 or CPT codes as I need to do those for > billing anyway. > > ``` Well, you can have them on a diagnosis or reason for encounter as well. Cheers, Sam [details="(attachments)"] ![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg) [/details] --- **Canonical:** https://discourse.openehr.org/t/snomed-loinc-mapping/14827 **Original content:** https://discourse.openehr.org/t/snomed-loinc-mapping/14827