FHIR Chat · Observation.Code use of LOINC vs SNOMED · implementers

Stream: implementers

Topic: Observation.Code use of LOINC vs SNOMED


view this post on Zulip Lauren Wolejsza (Feb 03 2017 at 14:33):

Good Morning! Historically our client has used SNOMED CT codes for recording blood pressure in its EHR system, however, the FHIR standard appears to use LOINC codes for observation.code (CodeableConcept) field. Is LOINC "bound" and/or "required" as the reference set for observation.code or can it be customized based on data mapping needs?

When looking at the blood pressure example on the FHIR site (http://www.hl7.org/fhir/observation-example-bloodpressure.json.html), it appears that via observation.component.code.coding you can specify multiple coding systems.

Based on this JSON for observation.component.code.coding (CodeableConcept), I expect it is possible to do something similar via. observation.code.coding (CodeableConcept).

Is this a correct assumption or no? If not, can you please provide an example for me that would be more appropriate here?

Thanks,
Lauren

view this post on Zulip Vadim Peretokin (Feb 03 2017 at 14:35):

Hello!

You can see in http://build.fhir.org/observation-definitions.html#Observation.code that the binding is just "example" - so you're fine with using SNOMED CT codes instead.

view this post on Zulip Lauren Wolejsza (Feb 03 2017 at 15:57):

Thought so. Thanks for confirming! Have a nice weekend!

view this post on Zulip Lloyd McKenzie (Feb 03 2017 at 16:32):

@Lauren Wolejsza It depends. For Observations in general, you're free to use whatever codes you like. However, in STU 3, FHIR has introduced a mandatory vital signs profile for a small set of observations. Diastolic ans Systolic blood pressure fall within that profile. Systems that capture such data using Observation must send one of the specified LOINC codes if they're sending information of this type if they want to be FHIR conformant. However, they're free to send a SNOMED code as well - i.e. multiple codings within the Observation.code CodeableConcept.

view this post on Zulip Lauren Wolejsza (Feb 03 2017 at 16:36):

Interesting. Yes, the impact of the change from DSTU2 to DSTU3 will certainly impact our work. Thank you for providing this additional detail.

view this post on Zulip Lauren Wolejsza (Feb 03 2017 at 17:06):

@Lloyd McKenzie Can you tell me what the other observations that would be included in this "small set" or tell me where I can find the list? It would help us in our refactoring efforts to account for this now and avoid rework where possible.

view this post on Zulip Lloyd McKenzie (Feb 03 2017 at 17:10):

http://build.fhir.org/observation-vitalsigns.html#bnc

view this post on Zulip Dave Carlson (Feb 06 2017 at 15:53):

@Lauren Wolejsza if your client is in the US, note that the US-Core profiles aligned with Meaningful Use require use of LONC for vital signs and labs. See http://hl7.org/fhir/us/core/StructureDefinition-us-core-vitalsigns.html

view this post on Zulip Lauren Wolejsza (Feb 06 2017 at 16:25):

Thanks everyone! This is very helpful! We will need to decide if it is necessary to store both code values at point of data entry or to utilize an existing reference/mapping in another system.

view this post on Zulip Grahame Grieve (Feb 06 2017 at 19:20):

I would typically expect that you would not do this at point of data entry; this is done by the system to mark things that are vital signs - so a configuration item


Last updated: Apr 12 2022 at 19:14 UTC