Specimen binding
Resource
https://www.hl7.org/fhir/specimen.html
Profile examples
https://simplifier.net/search?text=specimen&category=Profile&fhirVersion=STU3
Relevant Confluence pages
Pathology and Laboratory Medicine Clinical Reference Group
Resource – concept model mapping
Yellow rows denote SNOMED CT attributes where there is no specific FHIR counterpart.
Resource element (CodeableConcept) | FHIR ValueSet | SNOMED CT attribute | SNOMED CT range | Comments | Comparison |
|---|---|---|---|---|---|
Specimen.type Suggest rename to .substance | https://www.hl7.org/fhir/v2/0487/index.html A v2 value set reused for FHIR | JTC Suggestion: Expand the range of 370133003 |Specimen substance (attribute)| to incorporate the hierarchies listed. DK: 118168003 |Specimen source morphology (attribute)| has <<49755003 |Morphologically abnormal structure (morphologic abnormality)| as range and 118170007 |Specimen source identity (attribute)| has << 260787004 |Physical object (physical object)| in its range. | < 105590001 |Substance (substance)| (in which case method and site should also be populated) OR < 49755003 |Morphologically abnormal structure (morphologic abnormality)| OR < 260787004 |Physical object (physical object)| | A ConceptMap exists: https://www.hl7.org/fhir/conceptmap-example-specimen-type.html Another set of specimen type codes used for biobanking, SPREC, is available here (tables 1 and 2). | (^500121000057102 |urval provtyp laboratoriemedicin|) AND (<<123038009 |Specimen|:370133003 |Specimen substance|=*), n=44 |
|
|
| < 123038009 | Specimen (specimen) | | Pre or post coordinated concept which would preclude the population of other code fields. | ^500121000057102 refset with specimen concepts from Swedish microbiology labs, n=77 |
Specimen.collection.method | https://www.hl7.org/fhir/valueset-specimen-collection-method.html Extensional ValueSet | 118171006 | Specimen procedure (attribute) | | < 71388002 | Procedure (procedure) | 1 Sept could we be more specific to 17636008 |Specimen collection (procedure)|? | Note that the method would encompass the device used in obtaining the specimen <706041008 |Device for body fluid and tissue collection/transfer/processing (physical object)|
1 Sept Processing of the specimen may also be relevant - see 9265001 |Specimen processing (procedure)| | (^500121000057102 |urval provtyp laboratoriemedicin|) AND (<<123038009 |Specimen|:118171006 |Specimen procedure|=*), n = 24 |
Specimen.collection.bodySite Suggest rename to .source YGA suggests adding this rather than renaming so as to avoid overloading an element with heterogenous data. JTC agrees. | Include codes from http://snomed.info/sct | 118169006 | Specimen source topography (attribute) | | < 49755003 Morphologically abnormal structure | Previously << 442083009 | Anatomical or acquired body structure | Update 17 March: Not sure where this attempt to broaden collection site has come from. It's not showing as permissible in the MRCM. SV thinks the V2 mapping might be relevant ie https://www.hl7.org/fhir/v2/0487/index.html again also https://www.hl7.org/fhir/specimen-mappings.html#v2 | (^500121000057102 |urval provtyp laboratoriemedicin|) AND (<<123038009 |Specimen|:118169006 | Specimen source topography (attribute) |=*), n=48 500091000057101 additional refset with 66 body sites |
Specimen.processing.procedure | https://www.hl7.org/fhir/valueset-specimen-processing-procedure.html A v2 value set reused for FHIR (Most probably nothing in SNOMED CT corresponding directly to those codes) | 118171006 | Specimen procedure (attribute) | JTC: The use of this attribute here is incorrect as the definition of 118171006 | Specimen procedure (attribute) | is "... identifies the procedure by which a specimen is obtained.", not what is done with the specimen after collection | << 71388002 | Procedure (procedure) | | Random values exist: <<9265001 | Specimen processing (procedure) |
Sept 1 Note that a derived specimen can be indicated with the use of the parent element to point to a specimen that this specimen object came from, possibly in combination with a procedure object. | (^500121000057102 |urval provtyp laboratoriemedicin|) AND (<<123038009 |Specimen|:118171006 |Specimen procedure|=*), n = 24 |
Specimen.processing.additive-->Substance.code | Include codes from http://snomed.info/sct Include codes from http://snomed.info/sct | primitive, e.g. 445295009 | Blood specimen with edetic acid (specimen) | | << 105590001 | Substance (substance) | |
|
|
Specimen.container.type | Include codes from http://snomed.info/sct | Attribute type missing here? JTC: Is not a defining attribute so shouldn't be modelled as an attribute to the specimen. | ?? << 434711009 | Specimen container (physical object) | - only has 3 children. Useful values are distributed elsewhere.
Consider << 706437002 |Container (physical object)| still doesn't contain test tube however! Also 706046003 | Specimen receptacle (physical object) | | ValueSet not adequate, e.g. 337386000 | Test tube (physical object) | not included. Generally, little content in SNOMED CT. Terminology requirements?? SPREC, linked above also has a set of container types. |
|
Specimen.container.additiveCodeableConcept | https://www.hl7.org/fhir/v2/0371/index.html A v2 value set reused for FHIR | primitive | << 105590001 | Substance (substance)| |
|
|
Specimen.subject ??
Catered for by Specimen.source
|
| 118170007 | Specimen source identity (attribute) |
| << 125676002 | Person | OR << 35359004 | Family | OR << 133928008 | Community | OR << 49062001 | Device | OR << 276339004 | Environment | | Overlapping semantics between FHIR and SNOMED CT FHIR is not interested in specifying the class of subject, it would just link to the instance of the particular person resource. @Peter Williams check back to see who came up with Specimen.source and review with them. | (^500121000057102 |urval provtyp laboratoriemedicin|) AND (<<123038009 |Specimen|:118170007 | Specimen source identity (attribute) |=*), n=5 All "source identities" were devices, e.g. catheter tip, |
Specimen.type ?? Catered for by Specimen.source |
| 118168003 | Specimen source morphology (attribute) | JTC: This SNOMED attribute is a "modifier" of the Specimen substance | << 49755003 | Morphologically abnormal structure | | SNOMED CT distinguishes site, abnormal morphology, and substance when specifying the material contents of the specimen, while FHIR only has type and collection.bodySite |
|
Specimen.type ?? Catered for by Specimen.substance (previously type) |
| 370133003 | Specimen substance (attribute) | | << 105590001 | Substance (substance)| |
|
|
Comments
We've reviewed lists of specimen names from several Swedish labs as well as made comparison to AU and UK lists. The results have been very similar to Jeremy's findings: the lists are very heterogeneous in what dimensions of the specimen are inlured in the name. Thus, or belief is that an ideal solution would benefit from SNOMEDs ability to bridge such differences, and thus changing to specimen.substance is a step away from that solution.
Would welcome clarification of your thoughts on why it would be a bad idea to rename Specimen.type to Specimen.substance. In theory, the three axes of description outlined in the spreadsheet could be distributed across the three FHIR resource elements Specimen.substance, Specimen.Collection.method and Specimen.collection.bodySite ... possibly also adding in Specimen.Container.code. There are, however, a few edge cases in the V2 lists that wouldn't fit entirely cleanly into even that 4-way partitioning.
Or are you saying that it would make more sense to recommend not distributing the semantics across the elements of a FHIR resource, and instead recommending that all aspects of the nature of a specimen should be expressed only within a single self-contained SNOMED expression (either pre- or post-coordinated). In that scenario, I would agree that a single element called Specimen.type could be both adequate and appropriate...although I'd note that calling it Specimen.code would probably be more consistent with how similar functional elements in other FHIR resources are named.
Basically, this is what the SNOMED CT concept model is already doing, the suggestion is to move the overall meaning from the terminology to the resource. Given that what is seen in clinical and laboratory practice is various, often precoordinated, combinations, this would be example use of a terminology solution. This brings a streamlined solution to the 90ish (this is a real figure) percent at the cost of more juggling for the rest. Just my suggestion...
I'd agree completely that a streamlined solution makes sense, but the challenge remains to find and articulate the breaking cases to show that leaving all the compositional semantics entirely within an information model substructure (and so using relatively little of SNOMED's own compositional capabilities) isn't the right streamlining. Personally, I'm still convinced there ARE such breaking cases, but in the current climate they tend to be dismissed as falling unattractively within the 20 of the fabled 80:20 division.
Daniel, is your position here altered if there is also an addition of the proposed Specimen.code, which would allow for pre-coordinated specimen concepts to be used in the resource?
Yes, I believe a (hopefully coordinated) mix of pre- and post-coordination will be necessary.
This is the list we ended up with: https://browser.ihtsdotools.org/?perspective=full&conceptId1=500121000057102&edition=MAIN/SNOMEDCT-SE/2019-11-30&release=&languages=sv,en (not in anyway perfect or without overlapping concepts...). Further, we also found that the SNOMED hierarchies fully (yes fully!) supported aggregation from the specimen type detail level required by the laboratories to the level required by our CDC and our accreditation agency.
Many of the concepts are in themselves sufficient to describe the specimen substance/material, collection method and site, and only some require additional specification (in some cases), e.g. Skin swab, Wound...
So, the question then would be how to do the coordination.
/Daniel
I have added a few inline comments in the table. The SNOMED attribute Specimen source identity overlaps with the proposed Specimen.subject FHIR element. It is important when you are dealing with specimens that are collected for reasons other than testing the patient of record (e.g. control samples, fetus of patient, etc.)
The Specimen resource in FHIR 3.0.1 includes the two elements Specimen.type (which we've suggested renaming to Specimen.substance) and Specimen.collection.method. An HL7 V2 valueset is offered as an example valueset for each, but these are semantically very heterogenous valuesets, often also including aspects of other elements, especially specimen.site.
I've done a preliminary analysis of these two legacy HL7 V2 valuesets - the result is attached.