Stream: implementers
Topic: observation value[x]
Matt Zajack (Jul 01 2019 at 18:20):
Working on implementing some HL7 v2 ORU's into FHIR Observations. I think this might be a simple[r] one.
I see some great descriptions on Using Observations (https://www.hl7.org/fhir/observation.html#usingcodes), but valueString has no comments behind it. When is the valueString type appropriate to use? Specifically, how does it contrast with valueCodeableConcept.text for use when there is no valid code for "other" values? I have values such as "PLEASE REVIEW", "REPORT", "NONREACTIVE", "Not detected", "POSITIVE" Although I understand some of these may actual describe valueBoolean use cases, at this point I am just trying to capture the information into FHIR without doing "complex enrichment/transformation" where I might have to evaluate the associated LOINC, etc.
I will likely have quite a few Q's around these topics but wanted to start here. Thank you.
Alexander Kiel (Jul 01 2019 at 18:31):
Just transforming v2 messages into the technical FHIR format without proper semantics (profiles, implementation guide) may not be very valuable. Is there just a technical reason why you like to transform? Or do you simply like to start with something?
Matt Zajack (Jul 01 2019 at 18:41):
Pardon me for being dense--this is my first implementation project, but how would a profile or IG impact the use of Observation.valueString vs. Observation.valueCodeableConcept.text? I haven't explicitly created any profiles or IG but am trying to adhere to "stock" FHIR. We are getting v2 data from HIE's that contain a wide variety of tests (all LOINCs) and make it available for a wide variety use cases including analytics, care management, etc. So, I am working on getting data in the right places and advise the business on how to pull it.
Alexander Kiel (Jul 01 2019 at 19:02):
In a profile, you decide whether to use Observation.valueString or Observation.valueCodeableConcept.text for a particular observation. In a IG you can describe how to use all the created profiles together in order to establish a semantic rich set of resources. You should also look for existing IG's in your domain in order to get interoperable with others. Just using FHIR will give you almost nothing in the light of interoperability. I think https://www.hl7.org/fhir/observation.html#usingcodes describes the rules for using codings incl. "other" codes and free text fields very good.
Alexander Kiel (Jul 01 2019 at 19:04):
I would use valueString only if it's always free text. In case codes and free text are mixed, valueCodeableConcept with an explicit "other" code and use of valueCodeableConcept.text seems reasonable.
John Silva (Jul 01 2019 at 19:22):
@Matt Zajack -- from a V2 perspective, if the OBX-2 = "TX" or "ST" (maybe "FT") then it probably makes sense to map to valueString, if the OBX-2 = "CE" (older V2 pre-2.5) or CWE map to valueCodeableConcept.text (the case CNE - Coded with No Exceptions should always have a code)
Actually, this brings up the whole V2 to FHIR discussion of how to map OBX value types (OBX-2 Table 0125) -- should there be a recommended mapping of thes V2 types to FHIR data types, e.g. TS (TimeStamp) to valueDateTime, TM to valueTime, NM to valueQuantity, MO to ?? --- etc.)
Matt Zajack (Jul 01 2019 at 23:54):
Thank you both- You were blowing my mind, so I went back and studied a bit of the basics. So, the "Profile" is the basic StructureDefinition, right? I would say I'm going very broad, using the generic one https://simplifier.net/coreprofilesstu3/observation (but I use R4). @Alexander Kiel , this is OK to use, right? I see there are specific ones like observation-vitalsigns (https://www.hl7.org/fhir/observation-vitalsigns.html), but I want to capture all 6k LOINCs and not just the subset of 12 of them... It might be overreaching, but it's not practical to cover everything in such detail. In this way, I am creating Regular Expression rules to parse OBX-05_ObservationValues for things like Decimal values comparators (<, >, etc.), and text values. I want to choose the value[x] type that best represents that. Example values I receive from this HIE includes <0.2, >8 HOURS, 1.95, 10, BLOOD, NEGATIVE, Not Detected, and many more. I want to fit each of those where they "belong". That will work without needing a specific profile to cover every type disease/area, right?
@John Silva - very relevant, as I am mapping v2 to FHIR. OBX-02_valuetype from this HIE is all "FT" in my case and is unhelpful for your suggestion. I think if you did have an accurate valuetype, v2 to FHIR could use your suggestion and blanket-map values to the appropriate value[x]. However, I am having to write Regular Expression parsing as described above to try to cover all use cases. Is that taking on too much? Or, rather, is that making it too generic and washing out potential meaningful values for specific LOINCs?
John Silva (Jul 02 2019 at 00:22):
@Matt Zajack -- yes, too bad HL7 interfaces aren't done well -- that we have to resort to RegEx 'hacks' to figure out what normally should be specified in OBX-2. Some of your examples might map to valueRange, valueRation and other value[x] types. I don't have any better suggestions without understanding the type of data you are seeing in OBX-5 but it sounds like you do not have much of a choice but to parse the OBX-5 with RegEx. The problem with RegEx (as you probably already know) is that it is somewhat 'fragile' in its matching ability if you do not have examples of all of the expected patterns you need to match (and assuming they can all be uniquely determined by a RegEx expression).
Matt Zajack (Jul 02 2019 at 00:58):
@John Silva Good points about RegExp, and I definitely understand the limitations. So, it's not out of the question to try such a hack against every possible combination?
For reference, this is an example of data I need to parse (this is real-looking, but fake values, though the LOINC will match with potential values). I have a 205 row sample of ORUs and 58 unique LOINCs in this set alone. The pic below will highlight some difficulty and the wide range of Observation.value[x] data types I need to address:
pasted image
With this example alone, I will likely use, in order 1) valueCodeableConcept.text, 2) valueString, 3) valueQuantity, 4) valueQuantity, 5) valueQuantity, 6) valueQuantity, 7) valueBoolean. With each in its own Observation resource. What do you think? Would you agree with that?
John Silva (Jul 02 2019 at 01:14):
For #1, how would you know to use valueCodeableConcept.text vs valueString; do you have other examples for this same LOINC identifier that indicates it is normally a coded value? It also seems like all the valueQuantity can be inferred where the OBX-6 (unit code) is not empty. The other question is how do you encode <10 into a valueQuantity; does this fit better into a valueRange with low=0, high=10 (?). I'm not sure, maybe others have some experience/guidance. Also, you might want to bring this discussion to the "v2 to FHIR" stream.
Craig Newman (Jul 02 2019 at 12:17):
As far as mapping OBX-2 values to value[x] types, the v2-to-FHIR project has taken a rough first pass. This isn't an official or final list, but our first shot at it for comment. Please take a look and add your thoughts to the Confluence page.
https://confluence.hl7.org/pages/viewpage.action?pageId=40739972
Craig Newman (Jul 02 2019 at 12:20):
Are you doing the RegEx evaluation "just in time" as you're converting the OBX segment? If so, do you find that it leads to different "answers" for different messages and OBX-5 values? Does this cause problems for receiving systems? Does your system have access to the LOINC definitions for the codes and could it use the LOINC scale (narrative, quantitative, nomimal, etc) to help guide the decision?
Matt Zajack (Jul 02 2019 at 16:56):
@John Silva That's where my OP came from- not sure which one to use in that case... After reading Craig's v2-to-FHIR page, I think valueString is the better way to do it. I had originally based my decision on https://www.hl7.org/fhir/observation.html#usingcodes, because I thought it fell under "other". I think you are right, anything with OBX-06_unitcode can be a valueQuantity. Your other question about <10... the FHIR Quantity data type allows for comparators--https://www.hl7.org/fhir/datatypes.html#Quantity. So, I will use that in valueQuantity instead of valueRange.
@Craig Newman You coordinate/own the v2-to-FHIR effort, right? I have been very interested in contributing. For your questions:
1) Yes, JIT- converting on-the-fly using some RegExp.
2) Yes, it does lead to different answers, and I realize much of this is context-sensitive to the specific LOINC (OBX-03-01); however, using the 80/20 rule I hope we can accurately capture most values to be useful for business, analytics, research, care. At this point we have no receiving system but are working with business users one-off to determine if what we have works for their use case and improve as we go.
3) LOINC definitions for codes would be amazing! Where can I access such information? We do have plans for a terminology server that may do this. OBX-02_valuetype is not well-populated from our source (all are labeled as FT), so we can't rely on that.
John Silva (Jul 02 2019 at 17:32):
@Craig Newman -- I tool a quick look at the V2 OBX-2 mapping on Confluence; most of the mapping makes sense. I'll try to get back to you later with some specific questions/comments
John Silva (Jul 02 2019 at 17:33):
@Matt Zajack - Ah, yes Quantity datatype defines the comparator. I haven't used it so I didn't realize it was there.
We had a situation where the OBX-5 value was reported as a range, e.g. [0-5] (or 0-5), we mapped that to valueRange.
Craig Newman (Jul 02 2019 at 18:24):
@Matt Zajack Hans Buitendijk and I are coordinating the v2-to-FHIR project. We are always looking for input. The call information is on the main project page. Let us know if you have any questions.
The LOINC website should have the information you need. Section 2.6 of the LOINC Users Guide has a descriptions of the different scales (which hopefully will help guide a choice of value type). Then each LOINC code should include in its definition the scale of the observation. I don't have a good real-life feel for how strictly systems stick to the LOINC scale type. It wouldn't surprise me if there was some variation, but hopefully it's generally predictive
Matt Zajack (Jul 12 2019 at 18:32):
Wanted to provide a wrap up and thank you both @Craig Newman and @John Silva for chiming in on this thread. Working with my dev team, we decided to create a "maturity model" for incorporating the ORU lab results into Observation.value[x]. Quick-and-dirty at first and more refined as we tackle specific business use cases.
We will start by capturing anything with a populated OBX-06_unitcode as a valueQuantity and use [simple] Regular Expressions on OBX-05_value to look for the comparator. Save some specific valueBoolean value types we will identify, everything else will go into valueString. Next maturity levels include dataAbsentReason and applying a specific Profile, like the Vitals, to get much more strict requirements around the most important use cases.
Last updated: Apr 12 2022 at 19:14 UTC
