Stream: implementers
Topic: Observation.code Comment
Jason Teeple (Aug 28 2020 at 18:54):
Hi all,
In Observation.code - code has a cardinality of 1.1 - however the comment appears to be conflict with the cardinality:
The typical patterns for codes are: 1) a LOINC code either as a translation from a "local" code or as a primary code, or 2) a local code only if no suitable LOINC exists, or 3) both the local and the LOINC translation. Systems SHALL be capable of sending the local code if one exists. When using LOINC , Use either the SHORTNAME or LONG_COMMON_NAME field for the display.
Is point 3) incorrect?
Thanks - Jason
Michele Mottini (Aug 28 2020 at 19:00):
It is a CodeableConcept that supports a list of Coding - each specifying a separate system and code
Michele Mottini (Aug 28 2020 at 19:01):
For example:
"code": {
"coding": [
{
"system": "http://acmelabs.org",
"code": "104177",
"display": "Blood culture"
},
{
"system": "http://loinc.org",
"code": "600-7",
"display": "Bacteria identified in Blood by Culture"
}
]
},
Jason Teeple (Sep 08 2020 at 18:22):
Jason Teeple said:
Hi all,
In Observation.code - code has a cardinality of 1.1 - however the comment appears to be conflict with the cardinality:The typical patterns for codes are: 1) a LOINC code either as a translation from a "local" code or as a primary code, or 2) a local code only if no suitable LOINC exists, or 3) both the local and the LOINC translation. Systems SHALL be capable of sending the local code if one exists. When using LOINC , Use either the SHORTNAME or LONG_COMMON_NAME field for the display.
Is point 3) incorrect?
Thanks - Jason
@Robert Dieterle Would you know who can help answer?
Michele Mottini (Sep 08 2020 at 18:27):
@Jason Teeple I answered above....
Robert Dieterle (Sep 08 2020 at 19:45):
AS Michele indicated, the requirement is only one code concept. However, since it is a CodableConcept, you can have one coding using LOINC and another with a local code (as long as the concepts are the same). Since the binding in the base resource is only an Example, there is no requirement to use a LOINC code so you can use any of your examples.
Jason Teeple (Sep 09 2020 at 14:46):
Michele Mottini said:
Jason Teeple I answered above....
@Michele MottiniMy apologies, I did not interpret the above as an answer, just an example. It appears that if a Payer has both LOINC and local code, we are to provide both, is that correct? In reviewing with our mappers, the comment in Observation.code is unhelpful as it conflicts with the cardinality. Based on @Robert Dieterle response, b/c the datatype is CodeableConcept, we are allowed to provide both LOINC and Local code.
Michele Mottini (Sep 09 2020 at 14:50):
if a Payer has both LOINC and local code, we are to provide both, is that correct?
Yes, it is a good idea to provide both - it is not a requirement though
Robert McClure (Sep 12 2020 at 19:53):
@Jason Teeple I believe your confusion is in how CodableConcept works. It is a single object (hence 1..1) within which you can include multiple codings, one coding for LOINC and one for the local code.
Jason Teeple (Sep 14 2020 at 10:56):
Robert McClure said:
Jason Teeple I believe your confusion is in how CodableConcept works. It is a single object (hence 1..1) within which you can include multiple codings, one coding for LOINC and one for the local code.
Thanks @Robert McClure It was less confusion on how CodeableConcept works and more so on the definition not being clear. As IGs are getting implemented by mappers and devs, we are finding that some comments and definitions in the structure definition are either vague, confusing, or untouched (not updated from the resource).
Robert McClure (Sep 14 2020 at 13:05):
I agree the comment for observation.code is more about the datatype then it is about the element - pretty confusing.
Last updated: Apr 12 2022 at 19:14 UTC
