Stream: genomics / eMerge Pilot
Topic: Usage of LOINC code 81247-9 for Genetic tests
Mullai Murugan (Mar 07 2019 at 00:30):
Is the usage of the LOINC code 81247-9 as a code value for the code field in the DiagnosticReport resource applicable for all types of genetics tests e.g. Whole Exome Sequencing, Whole Genome Sequencing, Exome Panels etc.?
As also detailed in a gforge tracking item #19831
Kevin Power (Mar 07 2019 at 14:24):
I would suggest that identifying the type of test would be more appropriate in Observation.method or perhaps Observation.device - but considering our wide variety of Observation profiles, I am not sure of the best one to use. This is another topic we touch on occasionally, but have yet to define concrete guidance.
Bret H (Mar 08 2019 at 14:08):
agree with Kevin. Just adding that it might be worth looking at ability of the observation.code to have more than one LOINC code. If you fill out the details in the profile then the use of the generic LOINC code and specific LOINC code could be isomorphic (i.e. valid).
Mullai Murugan (Mar 15 2019 at 16:46):
@Kevin Power @Bret H I apologize for inadvertently labeling this as a type of genetic test. The DR resource refers to this field as the name/code for this diagnostic report. This is a fixed value and thinking more about this, a code indicating that this is a genetic test seems appropriate for computation but in that case, where do we include the lab defined name of the test in the DR? As labs seem to mostly have custom names for their tests, it might not be easy to represent the same as LOINC codes? I apologize if I misunderstood or misrepresented any information.
Kevin Power (Mar 15 2019 at 19:03):
The test would be in the ServiceRequest.code
Mullai Murugan (Mar 15 2019 at 21:32):
@Kevin Power wouldn't we want the same included in DR too? Along the lines of 'these are the results of test 'x'
Kevin Power (Mar 15 2019 at 22:53):
You can, sure. You can include multiple "DiagnosticReport.code.coding[]" values if you wish.
Mullai Murugan (Mar 15 2019 at 23:45):
Sorry, just for my understanding, so it is a 1..*? Isn't the system value fixed to LOINC?
Lloyd McKenzie (Mar 16 2019 at 00:35):
We don't fix the system anywhere, though sometimes we require that at least one of the coding repetitions matches a specific LOINC code. When we do that, additional codings from LOINC or other code systems are still permitted.
Jamie Jones (Mar 25 2019 at 17:07):
I think there is confusion here caused by the logical table format and the part where there is a CodeableConcept named "code." We require one specific system/code pair to be sent as part of "code," and everything on the table is 1..1 so it looks like we are forcing all the values. However, the upper code is a CodeableConcept, which has 0..* codings and up to 1 text.
Jamie Jones (Mar 25 2019 at 17:16):
That said, it looks like we also specifically constrained the number of codings on DiagnosticReport.code.coding to 1..1 in the profile spreadsheet so this may be an error? Unsure if our current spec actually allows sending multiple codings or if that's just how it's supposed to look...
Bret H (Mar 25 2019 at 19:08):
@James Jones does our github show when that was done?
Jamie Jones (Mar 25 2019 at 19:14):
not very well, it may have been there since the original import
Kevin Power (Mar 25 2019 at 19:19):
I am honestly not sure that the current GenomicsReport.code.coding 1..1 is meant to really constrain it to only allow a single code, or if that means that slice must have that single code, but we can use other slices? I think it means the latter. It does display differently than our Observation.code options do. Might need @Lloyd McKenzie or @Patrick Werner to weigh in with their expertise.
Bret H (Mar 25 2019 at 19:33):
The DiagnosticReport Resource does not look like it was constrained. What about DiagnosticReport.category?
Lloyd McKenzie (Mar 25 2019 at 20:43):
The 1..1 should be on one of the slices. It's saying there should be one coding that matches. We shouldn't constrain the cardinality of coding except for a slice. (And we're better off defining a pattern for the overall CodeableConcept than defining a coding slice these days because that's lighter weight)
Last updated: Apr 12 2022 at 19:14 UTC
