Stream: Orders and Observation WG
Topic: Specimen Containers and holders
Riki Merrick (Dec 05 2019 at 22:06):
We are working on identifying all elements described in the Specimen DAM (http://hl7.org/implement/standards/product_brief.cfm?product_id=499) to FHIR resources (most of them as extensions).
As part of this we are looking at the area of container (touches the specimen) and holders, storage equipment and locations a specimen can be located.
Currently FHIR only uses the term container and it can only be described within the context of the specimen and specimenDefinition resources.
We would like to keep the distinction between containers and any other holders etc.
We need support for nesting of containers in holders, holders inside holders / storage equipment - currently we have a gForge tracker (now jira item) to make container backbone recursive - we would like to change that to reference holder instead, BUT ALSO are trying to figure out if using this as backbone element only is sufficient.
We are looking for input from YOU as to what will be most appropriate:
#1 For the specimen resource we came up with these 3 options:
Option 1: add reference to device resource used to describe the holder / storageEquipmentComponent / StorageEquipment either:
1a under specimen.container instead of the currently suggested backbone of specimen.container.container (which will most likely be an extension)
1b separately direct under specimen
Option 2: add backbone element to specimen.container for holder
Option 3: remove container backbone element and add reference to device which then would describe the container / holder / storageEquipmentComponent / storageEquipment
We think that option 3 may provide the most flexibility to accomodate the nesting as well as allow for description of containers outside of being associated with a specific specimen already. For all options using reference to device we think we may need some extensions to the device resource to accommodate existing container attributes
#2 For the specimenDefinition resource, do we want to replace the container backbone element with a reference to deviceDefinition (which may need some extensions to accommodate existing container attributes)?
Please send your thoughts back to this list by COB 12/9/2019 - thank you for your input!
Riki Merrick (Dec 17 2019 at 20:03):
From the minutes of the catalog call on 12/6/2019 (https://confluence.hl7.org/display/OO/Catalog+Call+Minutes+December+6%2C+2019):
Discussion on specimen container vs other elements
See zulip chat for the problem statement: https://chat.fhir.org/#narrow/stream/179256-Orders-and.20Observation.20WG/topic/Specimen.20Containers.20and.20holders
For the catalog group this affects specimenDefinition:
In specimenDefinition we would replace the container backbone with reference to deviceDefinition, if we can be sure we can add the additional elements into the deviceDefinition (we prefer Option 3 with this caveat)
deviceDefinition does not have any required elements we don’t need, so that works out ok
Need to merge the values for valueset deviceType to include what we currently have in containerType - that can also help with the differentiation between containers and other kind of things like the holders, storage equipement
For catalog not sure if we would need to define holders (maybe for handling description)
Will need to add deviceDefinition to the lab catalogs
Marc Eden (Jun 21 2021 at 11:17):
Hello everyone,
I am quite new to the FHIR chat and in general to the underlying mechanisms of the working groups and standardization. However I'm interested in solving the issue with Specimens, having a precise location, that are collected in a hierarchical structure like racks, trays, freezers, rooms, buildings, sites, etc…
Is there any update on this, or did I miss something on that topic? Thank you for any hints or feedback!
Lloyd McKenzie (Jun 24 2021 at 01:30):
Seems like it would be reasonable to at least have an extension that could indicate the Location where the Specimen currently resides. (The Location resource would handle the recursive handling of rack inside tray inside freezer inside room, etc.) @Eric Haas @Hans Buitendijk?
Lloyd McKenzie (Jun 24 2021 at 01:30):
(Oh, and welcome to the community @Marc Eden :smile: )
Eric Haas (Jun 24 2021 at 01:50):
@Riki Merrick
Riki Merrick (Jun 24 2021 at 02:30):
Welcome @Marc Eden - we are considering freezers, racks and trays devices and devices have a location. There is work ongoing at IHE to define the Specimen Event Tracking (SET) profile - it should be published soon, though that looks at it in the V2 world, but describes the different use cases around specimen movement. We usually tlk about these things on the specimen project calls, which are Mondays 2 - 3 PM ET (
Riki Merrick (Jun 24 2021 at 02:31):
@Marc Eden - user error - I meant to insert a paragraph - here are meetign minutes from last year where we had discussions that also have links to the FHIR trakcers, but I have NOT looked where those are: https://confluence.hl7.org/display/OO/Specimen+Call+Minutes+February+24%2C+2020 ... and the link to the call: http://www.hl7.org/concalls/CallDetails.cfm?concall=55495
Lloyd McKenzie (Jun 24 2021 at 16:21):
@Riki Merrick - does it seem reasonable to have a link from Specimen to Location to indicate 'current' location? (We do that with Devices)
Rob Hausam (Jun 24 2021 at 22:52):
Yes, that's a reasonable suggestion, @Lloyd McKenzie. We've addressed it in FHIR-21280, and also related is FHIR-22823. The one thing that I think maybe we didn't do (or at least didn't do sufficiently) is look at whether we need to re-open FHIR-21280 and no longer add Specimen.container.location, since with FHIR-22823 we will have Specimen.container.device.location - and I'm sure we won't want to have both. @Riki Merrick @John David Larkin Nolen
Riki Merrick (Jun 26 2021 at 14:16):
@Robert Hausam <rrhausam@gmail.com> @John David Nolen
<jdlnolen@gmail.com> @Lloyd
McKenzie <lloyd@lmckenzie.com>
I thought we wanted the location to be on container (=device) because in
reality a specimen is always in a container (or in the analyzer).
Thanks @Robert Hausam <rrhausam@gmail.com> for pulling in the FHIR trackers.
So I think we should pull these up on next week's specimen call = Monday
2-3 PM ET.
Riki
Lloyd McKenzie (Jun 26 2021 at 21:10):
Device is an option, though it's a level of indirection that may make querying a bit difficult.
Marc Eden (Jul 14 2021 at 09:32):
Thanks everyone for your warm welcome! :) And of course for your suggested approaches and the detailed information. I will have a look at all the linked documents and discuss the insights with out team. Again, thank you for your helpfulness – that's not naturally in such specialized communities. :pray:
Last updated: Apr 12 2022 at 19:14 UTC
