Stream: implementers
Topic: Coding Data Type Extension
Lauren Wolejsza (Jan 30 2017 at 15:29):
Has anyone attempted or needed to create an extension for the Coding data type to incorporate Reference Range information? For some reason (awaiting for clarification), our FHIR server designers added an extension to this data type rather than using the FHIR-provided Reference Range data type. Curious if anyone has encountered a use case to justify this kind of extension.
Eric Haas (Jan 31 2017 at 01:41):
I am not sure what you mean by reference range information for a code in coding. What is the specific use case. To me a reference range for a coding is akin to valueset for the element.
Eric Haas (Jan 31 2017 at 01:45):
if you mean to have an Observation with a coded value then the reference range could be "not detected" for example and that could be represented using referenceRange.text element
Lauren Wolejsza (Jan 31 2017 at 12:56):
@Eric Haas Good Morning! Thank you for responding. Please see the attached Word doc that contains screenshots of the extension our design team wants to implement. My role as the data analyst is to figure out why this extension is necessary given the patient-generated mobile application data we will be storing into a FHIR-based database via a FHIR API.Data-Type-Extension-Example.docx
Lloyd McKenzie (Jan 31 2017 at 13:50):
I can't think of why ReferenceRange would be included in the Observation.code - the purpose of that element is to capture what type of observation is occurring. The ReferenceRange is captured elsewhere in the Observation.
Lauren Wolejsza (Jan 31 2017 at 14:41):
Exactly! However, ReferenceRange does not appear in other resources which is why I think the designers added this extension to this data type. Our challenge is having multiple existing and legacy mobile and web-based applications all trying to utilize the FHIR standard as it exists today without the ability to change the legacy data structures that were built before the decision to utilize the FHIR standard for patient-generated data. If anything, these kinds of extension decision continue to confuse me without clear justification from our design team.
Eric Haas (Jan 31 2017 at 16:10):
So I think there is some confusion here: if you want to limit a value to a set of codes then defining an Observationprofile with a valueset binding would be the best approach. Without specific examples I can't really see the need for the extensions you all have defineed. I certainly agree with Lloyd that it doesn;t belong on Coding. I can imagine perhaps having a set of codes ( a,b,c) that are considered "normal" and perhaps you could have an extension on ReferenceRange with something like:
normalCodes 0..* type codeableConcept
Eric Haas (Jan 31 2017 at 16:11):
An actual concrete example would be great to help us understand this.
Lauren Wolejsza (Jan 31 2017 at 16:15):
Thank you for the input so far! I do apologize for the generality here, however, we are only just starting to refactor our mobile applications to utilize the HAPI FHIR API and encountering these extension decisions on a one by one basis. Also, we do not have any "real" data yet as we do not have access to the legacy applications. Very frustrating situation at this point. Thanks again! I may come back to this topic once we have a use case and/or example for this extension.
Rob Hausam (Feb 01 2017 at 21:15):
I agree the the reference range shouldn't be handled as an extension on the Coding data type.
Last updated: Apr 12 2022 at 19:14 UTC
