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
(attachments)
