Stream: implementers
Topic: Representing "semi-quantitive" results
Colin E. (Feb 17 2021 at 19:35):
In UK Pathology Lab practice there are a number of test types that are reported in a "semi quantitive" form. Generally that means the result is reported as a text value selected from a fixed set of options that are on an ordinal or interval scale. In some cases there is a measured number under this and the result value comes from grouping/clustering the number into (e.g.) a High|Medium|Low group.
However some results are read directly, with no numeric value involved. An example is a "dip test", where a test strip is dipped in the sample (e.g. Urine) and the result is read directly as a colour change or a code becoming visible. A test like this might be reported as a value from the set-
**Negative **| **Trace **| **+** | **++ **| **+++ **| **++++**
To understand this the recipient (human or machine) needs to have both the Value and the definition of the scale range.
I've been looking at how to represent this in a FHIR message, and i've come up with a variety of answers, none of which looks very natural. The options I've considered include-
1) "Precoordinating" every result with the scale information into a big text string
2) A single unique CodeableConcept for each possible value, from which the receiver can infer the scale (as a ValueSet or SNOMED RefSet)
3) Stretching the use of multiple Codes within a CodeableConcept to transmit the Value and Scale separately
4) Stretching (a lot...) the Quantity data type to send the required information
I would like to know-
Has anyone met and dealt with this type of data before, and if so how?
Are there any good rules of thumb on when "creative" use of a standard Resource type becomes possible mis-use, and the right thing to do is consider an Extension instead?
Rik Smithies (Feb 17 2021 at 19:48):
Hi Colin, these look like coded values, that would go in Observation.valueCodeableConcept. When a code goes into an attribute of a resource there is no need to put the definition in the resource too. The definition of the code is a fixed thing and is not communicated in every message, but in the reference value sets and code systems that support the whole application.
Lloyd McKenzie (Feb 17 2021 at 22:39):
There's a coded ordinal representation that allows you to convey a code along with its numeric value. But that doesn't convey the overall range. For that, you'd need the valueset drawn from. Coding does have an extension that allows you to indicate that if you wanted.
Colin E. (Feb 17 2021 at 23:15):
Lloyd McKenzie said:
There's a coded ordinal representation that allows you to convey a code along with its numeric value. But that doesn't convey the overall range. For that, you'd need the valueset drawn from. Coding does have an extension that allows you to indicate that if you wanted.
There's a coded ordinal representation...
Is that the ordinalValue extension?
Coding does have an extension that allows you to indicate (the valueset drawn from)
That's a key piece I was missing. Can I ask where it is documented? Interested to know if it only supports FHIR ValueSets, or also allows references to SNOMED RefSets.
The issue (I think) is that a single term like "+++" could appear in multiple valuesets. I understand some dip tests max out at "+++" but others go to "++++". If the valuesets cover different overall ranges then you need to know what the range is to (a) label the display properly; (b) interpret the value.
Lloyd McKenzie (Feb 18 2021 at 00:00):
Then https://build.fhir.org/extension-valueset-reference.html is probably what you're looking for. It would tell you what choices were available when the code was chosen
Colin E. (Feb 18 2021 at 01:34):
Thank you, much appreciated. More reading to do... I see this last one is a FHIR 5 extension. In principle we're sill supposed to be targeting STU3 at this point, but I assume an extension can be "backported" to an earlier FHIR release locally if required.
Lloyd McKenzie (Feb 18 2021 at 01:54):
It existed in STU3 too - http://hl7.org/fhir/STU3/extension-valueset-reference.html
Rik Smithies (Feb 18 2021 at 10:20):
It might be better to define multiple code systems for the different ranges (even if the individual codes and/or displays look the same) rather than multiple value sets. The context of the code system is always available in the message, so no need for an extension to send a value set - which is less likely to be understood.
Colin E. (Feb 18 2021 at 18:50):
Thanks for the suggestion Rik. I need to go away and think about that, and maybe come back to you. I must admit one of the challenges of FHIR is that there are often many ways to achieve something, and quite a few ideas about the best approach.
However I do appreciate the helpful feedback, it's a lot better than grappling with the docs in silence ;-)
Lloyd McKenzie (Feb 18 2021 at 20:18):
Yup. There are frequently multiple ways to skin the cat - and different trade-offs in doing so. The discussion forum helps create awareness of the options, the tradeoffs, and what others are doing. At worst, it helps understanding. At best, it leads to convergence and maybe even updated documentation to guide those who come after.
Last updated: Apr 12 2022 at 19:14 UTC
