Stream: implementers
Topic: Custom code system
Dongtu (Aug 06 2019 at 09:50):
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "8310-5",
"display": "Body temperature"
}
],
"text": "Body temperature"
},
Can I use my url system and defined own code ?
Alexander Kiel (Aug 06 2019 at 11:00):
Yes you can do this. To maximize interoperability, the use of common codes systems is preferred.
Lloyd McKenzie (Aug 06 2019 at 14:03):
In the case of body temperature, the use of the LOINC code isn't just preferred, it's mandatory. (We do that only for about 10 vital signs observations.) So you should follow the pattern below. (This pattern is actually a good one to follow even for other types of Observations, such as lab results, etc. but there you're allowed to omit the LOINC code if it's too hard to translate.)
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "8310-5",
"display": "Body temperature"
},
{
"system": "http://some-other-system.org/fhir/CodeSystem/foo",
"code": "ABC-123",
"display": "Hotness indication"
}
],
"text": "Body temperature"
}
Lloyd McKenzie (Aug 06 2019 at 14:04):
Note that it doesn't matter which of the codings comes first
Lloyd McKenzie (Aug 06 2019 at 14:05):
This page shows the list of observation types where there are mandatory LOINC codes: http://build.fhir.org/observation-vitalsigns.html
Alexander Kiel (Aug 06 2019 at 14:19):
In the case of body temperature, the use of the LOINC code isn't just preferred, it's mandatory.
I would say it's only mandatory if you derive your profile from http://hl7.org/fhir/StructureDefinition/vitalsigns. Sure it makes absolutely sense to derive from vitalsigns in such a case but you don't have to.
Lloyd McKenzie (Aug 06 2019 at 14:27):
From the spec:
The following core profiles for the Observation resource have been defined as well. If implementations use this Resource when expressing the profile-specific concepts as structured data, they SHALL conform to the following profiles:
That means "If you are sharing the concept of Body Temperature (or any of the other covered concepts) using Observation, you SHALL conform to the listed profiles"
Lloyd McKenzie (Aug 06 2019 at 14:29):
So if you're sending Body Temperature, Height, Weight or one of the other vitals using Observation (as opposed to say DocumentReference with a wrapped PDF), then you're obligated to comply with the profile, which means you're obligated to use the specified LOINC code - though you're free to send any other Codings you like too.
Lloyd McKenzie (Aug 06 2019 at 14:30):
HL7 has done this because vital signs are so critical to patient care and because we believe that hard-coding mappings in these limited cases is both achievable and that the resulting interoperability is worth the cost it imposes on implementers.
Alexander Kiel (Aug 06 2019 at 14:50):
What should I do, if I have a vitalsign which has no LOINC code?
Lloyd McKenzie (Aug 06 2019 at 15:06):
Presuming that there's a code at all that identifies it as being a vital sign (and what kind of vital sign), then do a lookup and add the LOINC code too. (Similar to the example above.)
Lloyd McKenzie (Aug 06 2019 at 15:06):
The only ones you have to translate are the ones explicitly listed in the FHIR spec.
Lloyd McKenzie (Aug 06 2019 at 15:07):
But if you have a code that corresponds to any of those (even if your code might be more specific), then a translation to the mandated LOINC code is needed. (In fact a translation is required even if you have a LOINC code but it's more specific than the ones listed.)
Alexander Kiel (Aug 06 2019 at 15:37):
But what if I measured the body height with shoes on. For sure there is no LOINC code for that. In this case I should be allowed to have an "vitalsign" observation, which doesn't inherit from vitalsigns and uses no LOINC code.
The example of body height with shoes on might be not the best, because nobody would count that as vitalsign. But there are for sure observations which would count as vitalsign but have no LOINC code or the meaning behind the LOINC doesn't fit my observation practise.
John Moehrke (Aug 06 2019 at 15:41):
I think that one is covered -- 8352-7 http://r.details.loinc.org/LOINC/8352-7.html?sections=Comprehensive
Lloyd McKenzie (Aug 06 2019 at 15:42):
Height with shoes on is still a subtype of "height". The accuracy of height, weight, blood pressure, etc. will vary depending on the measurement mechanism and circumstance. But they're still height, weight and blood pressure and are expected to use the standard (and generic) LOINC codes.
Alexander Kiel (Aug 06 2019 at 15:50):
Ok that is interesting. How do I specify the LOINC code 8352-7 in an Observation?
Lloyd McKenzie (Aug 06 2019 at 15:59):
You would send the required LOINC of 29463-7 (Body weight) and would also send 8352-7 (Body weight - Clothing worn during measure) as an additional Coding.
Rute Martins (Aug 06 2019 at 18:25):
@Lloyd McKenzie doesn't that imply that there is equivalence between the codes (but there isn't)?
Lloyd McKenzie (Aug 06 2019 at 18:35):
It implies that both codes are encodings of the actual measurement taken (which they are). There's no expectation that all codings have identical granularity (and thus are not necessarily equivalent in meaning) however all should be encoding the same concept.
Lloyd McKenzie (Aug 06 2019 at 18:36):
As a different example, you might send an ICD9, an ICD10, a bare SNOMED code and a post-coordinated SNOMED code all for the same Condition. They wouldn't be equivalent, but they would all be appropriate encodings of the underlying condition.
Dongtu (Aug 07 2019 at 01:22):
In the case of body temperature, the use of the LOINC code isn't just preferred, it's mandatory.
How about other situations? Are there any difficulties with partners when I use my own Coding?
Is it accepted? If one partner send LOINC code and my fhir server isn't accept. Then they will say my server do not follow the hl7 standard? is that True ?
Lloyd McKenzie (Aug 07 2019 at 01:27):
The base HL7 standard sometimes mandates codes. For Observations, the only time we mandate is for very specific vital signs codes (see the spec). However, countries or organizations might define additional constraints. For example, in the U.S., the expectation is that Observations will use LOINC if a code exists. In the UK, the expectation is that you'll use SNOMED. Other countries have not made any determinations (at least not yet).
Dongtu (Aug 07 2019 at 01:38):
That mean the coding is uniformly used in a country or an organization . If one system in US send msg to system in UK, it must use SNOMED instead of LOINC.
Thank you!
Lloyd McKenzie (Aug 07 2019 at 01:47):
Codes are sent uniformly within the set of applications that are bound by (or choose to comply with) an implementation guide. In some places, compliance may be regulated. In other cases, it might be tied to payment. In many cases, it's voluntary. And in the majority of cases if you look world-wide, no implementation guides exist that are intended for the scope the application is intended for (though there may be implementation guides from other jurisdictions, disciplines or areas that could be informative/useful).
Richard Townley-O'Neill (Aug 07 2019 at 04:38):
@Dongtu
If one system in US send msg to system in UK, it must use SNOMED instead of LOINC.
Almost. The UK system might not prohibit LOINC, so :
If one system in US send msg to system in UK, it must use SNOMED, it may also send LOINC.
Lloyd McKenzie (Aug 07 2019 at 05:29):
(And for certain vital signs, it must send LOINC).
As a general rule, you can always send more codes than are required. If you have different recipients who expect different codes, it's generally fine (and a whole lot cheaper) to build a single interface and expose all of the different translations of the relevant concept and let the receiver grab the one they recognize/prefer out of the instance.
John Silva (Aug 07 2019 at 09:45):
How does this principal work when the codes from one coding system don't "directly match" those from another? There are many coding systems that do not have a one-to-one match with codes in another system; it has been this way since medical coding systems were invented. The NLM metathesaurus tries to do this code system mapping but inevitably there are cases where the mapping isn't complete and definitely not one-to-one.
Rob Hausam (Aug 07 2019 at 13:23):
Yes, this is certainly true and isn't going to change. The idea with sending multiple codes from different code systems is that the code that you send from each code system should be the one that most closely matches the intended meaning of the instance (or that is used to meet a specific requirement, as with the specific required LOINC codes for vital signs). This allows (and anticipates) that there almost always will be differences in the granularity and closeness of the match if you compare across the different code systems, but in each case the match should be the closest that the code system provides (with some additional allowances, such as whether SNOMED CT post-coordinated expressions will be used, or not).
Lloyd McKenzie (Aug 07 2019 at 14:26):
The objective isn't to send equivalent codes. The objective is to encode the concept in an appropriate way in each system. One code system might say "metabolic disorder". Another might say "diabetes". Another might say "uncontrolled early-onset diabetes". All would be appropriate encodings for the same concept in their respective code systems. But we're not saying that "uncontrolled early-onset diabetes" is equivalent to "metabolic disorder"
John Silva (Aug 08 2019 at 00:56):
@Lloyd McKenzie this doesn't make any sense to me ("metabolic disorder" vs "diabetes" vs "uncontrolled early-onset diabetes") since each of these are obviously different medical conditions in terms of severity and treatments; the only thing that they seem to have in common is that have a common 'parent concept'. If someone were doing a clinical study on 'early onset diabetes' or 'type 1 diabetes' these other codes wouldn't do them much good unless the codes are at the required level of specificity was available in the list of codes (CodeableConcept). Also, more importantly, someone treating type-1 diabetes vs 'diabetes' (unspecified) needs to use a completely different treatment plan.
Jean Duteau (Aug 08 2019 at 01:00):
Lloyd McKenzie this doesn't make any sense to me ("metabolic disorder" vs "diabetes" vs "uncontrolled early-onset diabetes") since each of these are obviously different medical conditions in terms of severity and treatments; the only thing that they seem to have in common is that have a common 'parent concept'.
I think Lloyd's point was that if you had three different code systems and you were trying to represent a condition using all three that you would have to do the best you can. If you have equivalent codes, then you could send those. But if you wanted to encode "uncontrolled early-onset diabetes" and all you had in your code system was "diabetes" or "metabolic disorder", then that's what you'd have to go with.
We have probably all dealt with different code systems that have different levels of granularity. Even if you're just trying to send codes in ICD-9-CM and ICD-10-CM, you have to struggle to find the best equivalence sometimes. And that (I think) was Lloyd's point.
Lloyd McKenzie (Aug 08 2019 at 01:54):
Different codes are appropriate to different types of use. A large-grained code system may be sufficient for reporting/categorization purposes. A medium-grained code system is typically what's needed for billing. Finer-grained code systems are often ideal for clinical purposes (though not always used/available). The same resource might be shared for all three purposes and all three types of codes may need to be present. (And even within a particular use, granularity can vary. ICD-9 and ICD-10 are both used for billing, but they have different degrees of specificity. The key point is that it's fine to send all the codes you have as alternate codings and it's fine if they aren't equivalent - what matters is that they're all appropriately representing the same concept.
Grahame Grieve (Aug 08 2019 at 05:40):
where appropriate is a bus sized hole... but there's no way to come up with better language until the whole world converges on a single terminology. Don't hold your breath...
Michael Lawley (Aug 08 2019 at 06:24):
Hmm, are those rules are going to interact badly with Extensible binding disallowing subsumed codes? Or does that constraint also have a hole with the interpretation of "cover the concept (based on human review)"?
Grahame Grieve (Aug 08 2019 at 07:29):
that increases the difficulty in practice, but in principle the rules are orthogonal
Pieter Edelman (May 25 2021 at 19:05):
Circling back to an old discussion, I fail to understand how this works:
You would send the required LOINC of 29463-7 (Body weight) and would also send 8352-7 (Body weight - Clothing worn during measure) as an additional Coding.
As far as I can see, LOINC 8352-7 is not a statement _that_ there were clothes worn during measurement, but is used to define the question "what can you tell me about the clothes were worn during measurement?", where the answer can be "fully clothed with shoes", "fully clothed without shoes", etc. If you just send 8352-7 as an additional coding to your Observation, you still don't know much about the actual state of clothing. Can anyone enlighten me?
Lloyd McKenzie (May 25 2021 at 22:26):
You're right. 8352-7 is not a body weight observation. It would be appropriate for use as an Observation.component.code within a Body weight measure. While it could be captured as an independent observation, it would be less useful as such as it's providing essential context for the weight measurement and all essential information for the interpretation of an Observation is supposed to be within or directly linked from the Observation.
Pieter Edelman (May 26 2021 at 07:29):
Thanks for the clarification @Lloyd McKenzie.
The VitalSigns IG states in this particular case:
Body weight - To supplement this vital sign observation, 8352-7 - Clothing worn during measure and 8361-8 - Body position with respect to gravity MAY be included as additional observation codes.
Wouldn't it be more appropriate to say "... included as additional observation components"?
Lloyd McKenzie (May 26 2021 at 13:11):
I think so. Feel free to submit a change request. (And post a link here so I can watch it :))
Pieter Edelman (May 26 2021 at 19:37):
Here you go: https://jira.hl7.org/browse/FHIR-32787
Last updated: Apr 12 2022 at 19:14 UTC
