Hi all,
When you work with quantities it is possbile to add more units, sometimes, the use of different units have other LOINC-coding, this is for example with
LOINC:
LOINC LongName Component Scale exUCUMunits
2160-0 Creatinine [Mass/volume] in Serum or Plasma Creatinine Qn mg/dL
14682-9 Creatinine [Moles/volume] in Serum or Plasma Creatinine Qn umol/L
Would it be good if it was possible to add code per unit-kind in dv_quantity?
Or are there other suggestions
Thanks
Bert Verhees
Hi Bert,
I don’t think this is helpful. The source of truth in dv_quantity should always be the unit. I would not trust the LOINC code. It should be the responsibility of the original sender/documenter to make sure the correct LOINC code was used to match the SI unit. I would think this advice would apply whether one was using hl7v2, FHIR, CDA or openEHR.
Ian
Thanks Ian for the quick response.
From practical point of view you are right.
I think we need follow this advice.
But now let’s look at it from the Reference Model or LOINC point of view, maybe there some change would be welcome.
The problem is that different used units in measurements which are exact the same for the rest (method, substance, purpose), sometimes translate to a different LOINC-code.
In openEHR-archetypes (mostly used to build software) we want to constrain the sender in the units he can choose. We don’ t want our software to translate every possible unit to the unit we want to process. So that is why we offer some units for the sender to choose from. This constraining is done in DV-QUANTITY, following the openEHR-specs it is in UCUM syntax (it does not say UCUM-unit http://www.openehr.org/releases/RM/Release-1.0.3/docs/data_types/data_types.html#_dv_quantity_class ).
To be sure that the sender is using the constrained units and measuring the constrained item we need some coding. I was worried because of some discussion on an OpenEHR list in 2014, which discussed a similar problem. ( http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/2014-November/003393.html )
So, imho, the possibility to add LOINC-coding (or coding in general) to different unit-kinds in the dv_quantity-class to tell us what we are looking at, would be a good feature to support interoperability.
Bert Verhees
Hi Bert,
I don’t understand the use-case here.
if the lab result is being imported from a lab message, you import whtaever units are being recorded in the message.
If this is a situation where the lab test is being recorded via a data entry screen, and there is a potential for there to be more than one unit required. I would either just handle the association between loinc code and unit in the application, or clone the lab-test panel result-value to support two different values each constrained to the correct loinc code / unit combination.
Ian
Ian,
The problem is that we want to constrain the user in units which .
And the purpose of the coding would be to make the data which are stored, queryable/interpretable/interchangeable over the coding (if every unit-use in dv_quantity would have a coding)
Bert
Hi Bert,
Then I am not understanding your use-case.
You can use the template to constrain the lab units and/or code to be whatever you want. If there is actually a choice of possible units/codes, then I suggest that you create 2 contraints in the template one for each combination of code + unit.
As far as I can see that will do what you need.
Ian
That is indeed a way to do it. But I believe the feeling here is to not do it that way, and add no LOINC-term-binding to dv_quantity if this is the situation
Thanks for your attention and solution
Bert
I agree with Ian, at least for your case those those LOINC codes could be used to bind the container Element, but not the unit itself. Units are coded using UCUM standard, so they are already semantically queryable/interpretable.
Thanks David for your reply,
Just for the discussion, adding the LOINC-code to the element would suggest the underlying DV-QUANTITY uses the UCUM unit which is represented by the LOINC-code. That could cause a semantic error-situation.
The problem is that LOINC uses (sometimes) different codes for different units, especially when the units are not easy interchangable, like mol and g (gram)
Hi Bert,
“suggest the underlying DV-QUANTITY uses the UCUM unit which is represented by the LOINC-code”
That is not actually quite correct, any given LOINC code can be associated with a range of different units, and are only examples i.e do not restrict others. LOINC sometimes uses different codes for different classes of unit, not for specific units.
It does also have terms for the base substance e.g. http://r.details.loinc.org/Part/LP14355-9.html but when querying you would then to query on all of the variations of ‘creatinine’. Even more messy!
But if you want to clearly associate a specific LOINC code with valid unit(s) then it is possible to do that as I suggested before.
Ian
Ian,
2160-0 Creatinine [Mass/volume] in Serum or Plasma Creatinine Qn mg/dL
14682-9 Creatinine [Moles/volume] in Serum or Plasma Creatinine Qn umol/L
In my example, there are different codes for different unit-types. I agree that moles and mass are not easy interchangeable, but there are lab-tests in the use-cases where I work where it is allowed to use both, because we work with different countries having another way of notating lab-results.
Bert, I think you have a misconception there.
In your example there are not codes for different units. There are codes for different complex concepts: “Creatinine [Mass/volume] in Serum or Plasma” and “Creatinine [Moles/volume] in Serum or Plasma”. You cannot use those codes to code just the units of measurement. The unit codes are pure UCUM: mg/dL and umol/L.
In the openEHR archetype you don’t need to add a particular binding at the unit level of the dv_quantity. The unit value is already a standard and interoperable code. And as I said before, the LOINC codes are bindings for the container Element that will contain that specific measurement. You only have to model the archetype to match the two possible configurations:
choice {
ELEMENT { → Bind to: 2160-0 Creatinine [Mass/volume] in Serum or Plasma
DVQuantity {
unit { "mg/dL}
}
}
ELEMENT { → Bind to: 14682-9 Creatinine [Moles/volume] in Serum or Plasma
DVQuantity {
unit { "umol/L}
}
}
}
Thanks David,
I will suggest this to my employer.
Best regards
Bert Verhees
This is in my view also the correct solution and explanation. The only thing to add is that these bindings only make sense within archetypes specific to particular lab results, e.g. urinalysis or protein, or even just creatinine, depending on how the lab results / panels are modelled.
- thomas
Thanks for the confirmation, Thomas.
Bert
This does raise some interesting issues about querying loinc codes. It looks to me right now that you can’t easily search for ‘serum creatinine’ without including multiple codes or by using some sort of loinc aware terminology service which understands the internal relationships. Does anyone have experience with querying loinc?
Ian
This was helpful but still implies that some sort of terminology service is required
Very well thought out guidelines in the second part. Will be helpful in the discussion
Thanks
Bert
Helpful but do rely on having some fairly sophisticated terminology services and available mappings.
We should keep this dialogue going as we will be working in a mixed loinc snomed environment in a uk project.
Ian
The use case discussed was our use case. All that has been explained makes perfect sense from a lab perspective (Mol and Mass are different test), however in our use case we do need to aggregate them.
In our case it is allowed to report have for example createnine in both mg/dl and mmol/l, in the software application it will be one field with a choice for the unit, we receive info from multiple labs in europe). We are also looking for the possibility for electronic exchange of HL7v2 messages in the future. We use the lab test observation (inlcuding specimem details) and lab test panel to record the test result. We try to bind with both SNOMED and LOINC (being flexible), on a template level I see only two solutions:
I now see two options:
Currently we prefer solution 1.
Best regards,
Wouter Zanen
De inhoud van dit bericht is uitsluitend bestemd voor de geadresseerde en kan vertrouwelijke en/of persoonlijke informatie bevatten. Als dit bericht niet voor u bestemd is, wordt u vriendelijk verzocht dit aan de afzender te melden en het bericht (inclusief bijlagen) uit uw systeem te verwijderen. Eurotransplant staat door de elektronische verzending van dit bericht niet in voor de juiste en volledige overbrenging van de inhoud, noch voor tijdige ontvangst daarvan. Voor informatie over Eurotransplant raadpleegt u: www.eurotransplant.org.
This message is intended for the addressee’s eyes only and it may contain confidential and/or personal information. If you are not the intended recipient, you are hereby kindly requested to notify the sender and delete this message (including attachments) from your system immediately. In view of the electronic nature of this communication, Eurotransplant is neither liable for the proper and complete transmission of the information contained therein nor for any delay in its receipt. For information on Eurotransplant please visit: www.eurotransplant.org
Ian McNicoll ian@freshehr.com 16/02/2017 11:04 >>>
Helpful but do rely on having some fairly sophisticated terminology services and available mappings.
We should keep this dialogue going as we will be working in a mixed loinc snomed environment in a uk project.
Ian