FHIR Chat · GF#17495 · Orders and Observation WG

Stream: Orders and Observation WG

Topic: GF#17495

Ralf Herzog (Jul 24 2018 at 15:02):

Created GF#17495 to initiate a debatte relating how reagents/substance should be stored in observation resource.

Reason:
IHE LAB-29 (OUL^R22) transaction uses the following structure (cut down to only needed/applicable elements for my problem):

MSH
...
{ --- SPECIMEN begin
    SPM
    [{ --- CONTAINER begin
        SAC
    }] --- CONTAINER end
    { --- ORDER begin
        OBR
        ORC
            [{ --- RESULT begin
                OBX
                [{INV}] // Used Substance/reagent information
            }] --- RESULT end
    } --- ORDER end
} --- SPECIMEN end

So in the v2 based LAB-29 transaction the used reagent/substance information (INV-Segment) is part of the result group, and in the result group the used device is also available (OBX-Segment) so both of them are related to the Result.

We would like to model something like this in FHIR via the observation resource, so we would like to have reagents/substance as a reference in the observation.

Some information for the background:

• Each Analyzer consists out of several modules (1-5) which contain up to two submodules
• Each Submodul could perform several different tests
• Each Test could use several different reagents
• Each Module (not submodule) could have several different reagents each with a unique expiration date/time, unique lot, ...
• Each Reagent could be unloaded and loaded to another Module
• Each reagent has a specific position on the Module (and could be identified via this (and the pipetting time)).
• Some Tests could be measured on different module/submodule combinations
• Observation is usually produced on the submodule level (but might be produced on the module or analyzer level)

I think this should not be done via the device resource, because else we would need for each reagent ever loaded to the module a separate device instance where the problem is that the reagents are not part of the submodule but of the module while the measurement was done (most of the time) on the submodule.

Easiest to model this would be to add the used reagent to the observation analog to the LAB-29 transaction of IHE. I think this need is quiet common on the big Analyzers (which might be needed to be verified). Perhaps a standard extension should be available for this use case.

corrected a typo

Ralf Herzog (Jul 24 2018 at 16:58):

Basically I would just want to have something like this added to the observation:

      {
        "label": "reagent",
        "id": "ObservationWithSubstance.reagent",
        "path": "ObservationWithSubstance.reagent",
        "short": "reagent",
        "definition": "Reference to used reagents to generate this observation",
        "min": 0,
        "max": "*",
        "mapping": [],
        "type": [
          {
            "code": "Reference",
            "targetProfile": "http://hl7.org/fhir/StructureDefinition/Substance"
          }
        ],
        "base": {
          "path": "ObservationWithSubstance.reagent",
          "min": 0,
          "max": "1"
        },
        "extension": []
      },

Grahame Grieve (Jul 24 2018 at 20:05):

Is this for in-lab messaging between instrument and LIS?

Ralf Herzog (Jul 24 2018 at 20:10):

Mostly yes.
I believe it could also be used for tracing results to device and reagents used (but I do not know if it is only needed inside a laboratory for traceability)...

Grahame Grieve (Jul 24 2018 at 20:10):

I have never seen details like that reported outside the lab

Grahame Grieve (Jul 24 2018 at 20:12):

I've never thought that Observation is scoped for in-lab comms. I've always that we'd get around to making fit for purpose resources for instrumentation management in a lab one day

Ralf Herzog (Jul 24 2018 at 20:14):

I would be fine with that, except that we (want to) start a prototype using FHIR ... When I was taking a look at observation resource I found much I liked and some missing stuff...

Grahame Grieve (Jul 24 2018 at 20:23):

so extensions for now then. In the lab messaging is a focused variant of device interaction, with a particular focus on calibration and reagents. And we also haven't done device control yet...

Ralf Herzog (Jul 25 2018 at 15:35):

I would not need too much device interaction, it is more for reporting of results as a kind of a prototype project.

Eric Haas (Jul 25 2018 at 19:37):

So Ralf is this the only extension you are looking for?

Eric Haas (Jul 25 2018 at 19:47):

added to last block vote I am trying to squeeze in.

Lloyd McKenzie (Jul 25 2018 at 20:01):

GF#17424 - if you made it not persuasive w/ mod and added the note I proposed in my most recent comment on the tracker, I could live with that.

Eric Haas (Jul 25 2018 at 20:29):

I just don't understand your use case. I responded by sayin:

Eric Haas (Jul 25 2018 at 20:29):

I don't think this guidance needs to be in the resource it is covered in FHIR documetation

option 1: Use an opaque identifier in the reference.identifer element - the use case Bob M has certainly needs to track the patient so a business identifer is perfectly appropriate here.

option 2 :or a the existing http://build.fhir.org/extension-data-absent-reason.html extension for the edge cases where there is no source.

Lloyd McKenzie (Jul 25 2018 at 20:37):

The FHIR documentation allows many things. There are going to be places where systems will process a specimen or pass around information about a specimen with no idea who it's associated with. The linkage to the patient would be outside that process - through the order number or by specimen id with a system that does know the linkage. I accept that there's a minimal set of information in the Patient resource that will likely be needed, so I can live with minOccurs=1, but I think it's important to call attention to the fact that you don't need a reference to a stand-alone resource.

Lloyd McKenzie (Jul 25 2018 at 20:39):

Note that if we think there's any likelihood that element won't be needed by systems a tall, the solution isn't "use dataAbsentReason", it's to make the element optional. dataAbsentReason is a mechanism when systems need to know why data is missing. It's not a mechanism to let designers make something mandatory, while giving implementers an "out" to ignore the requirement.

Lloyd McKenzie (Jul 25 2018 at 20:40):

Making up an opaque identifier if one isn't needed also isn't acceptable. If a system doesn't need an element at all, then that element should be optional in the spec - even if 99% of systems will require it.

Eric Haas (Jul 25 2018 at 20:46):

my experience is there is always slot for a source. I'm afraid I don't follow your logic. in Observation status is required but a system may not have it so we should make it 0..1?

Lloyd McKenzie (Jul 25 2018 at 20:47):

We provide an explicit status of "unknown" for that case.

Lloyd McKenzie (Jul 25 2018 at 20:47):

Can't do that for a Reference

Eric Haas (Jul 25 2018 at 20:47):

We can give it a temporay ID though

Lloyd McKenzie (Jul 25 2018 at 20:48):

Making up data to satisfy an unnecessary mandatory is a kludge. It shouldn't be a mandatory

Eric Haas (Jul 25 2018 at 20:48):

why is that different than a contained reference to me its the shorter sweeter solution

Lloyd McKenzie (Jul 25 2018 at 20:49):

It's been argued that there's always a need for gender/birthdate. If that's valid, then contained resource would be the mechanism to do that.

Lloyd McKenzie (Jul 25 2018 at 20:49):

My preference would be 0..1

Eric Haas (Jul 25 2018 at 20:50):

The committee has deliberated and will pull for a separate vote.

Lloyd McKenzie (Jul 25 2018 at 20:52):

If the committee believes there will always be a reference to a stand-alone resource or a need for at least a contained resource, that's fine. But it's not kosher for them to say "just send something to satisfy the mandatory" in the rare case you don't need it. If they believe the rare case exists, make it 0..1 and in the usage notes indicate that it should almost always be present.

Eric Haas (Jul 25 2018 at 20:54):

There are going to be places where systems will process a specimen or pass around information about a specimen with no idea who it's associated with.

Eric Haas (Jul 25 2018 at 20:55):

is not a use case is an assertion. I have trouble understanding what you are going to doing with a specimen information if you don't know where it came from.

Lloyd McKenzie (Jul 25 2018 at 21:02):

Some of the systems in the chain will know/care who the patient is. But not all systems will. We need to allow that the back-ends of some systems aren't going to persist patient data because they don't care - even though they do track the specimen under test.

Lloyd McKenzie (Jul 25 2018 at 21:02):

Specimen is going to be used in the back-end lab processing, not just in the EHR <-> Lab interaction

Eric Haas (Jul 25 2018 at 21:12):

dammit Lloyd I was going to use the QR.questtionnaire as another example but its 0..1 :-)

Lloyd McKenzie (Jul 25 2018 at 21:16):

:D

Lloyd McKenzie (Jul 25 2018 at 21:17):

You may have legacy systems that have responses that don't actually have a Questionnaire instance to point to or anything useful to say.

Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Jan 03 2022 at 19:56):

@Grahame Grieve It is true historically this info hasn't been reported outside the clinical lab, but with COVID, HHS is requiring info about reagents and instruments (UDIs) to be reported as part of regulatory requirements.

That said, what is typically done for automated chemistry, may not apply to other areas of the laboratory. For example 4 reagents are utilized by hematology analyzers to produce "parameters" for CBC results typically reported. This could result in combinatorial explosion for some lab results if you consider calibrators, controls, lot numbers, etc. (as some at FDA have been requesting). The latter would be incredibly burdensome to clinical laboratories.

Also realize FHIR resources are pretty broad/generic to apply to many needs. (O&O has started talking about UDIs at times, especially on the Friday LIVD calls with IVD vendors, like @Ralf Herzog .) The other issue is if any systems in the "information flow" don't have functionality, it will be difficult to implement (send/receive). O&O isn't aware of any LIS/LIMS that has FHIR functionality yet, much less for daily lab needs. If anyone becomes aware of LIS FHIR functionality, would be interested to learn more.

Last updated: Apr 12 2022 at 19:14 UTC