Stream: genomics / eMerge Pilot
Topic: Housing extended test, methodology and reference information
Mullai Murugan (Mar 07 2019 at 00:25):
As illustrated in the attached file, the highlighted text includes test information, methodology, references etc. about a genetics test. Is the field currently available to house method information part of the Observations resource? And is this a coded value? If so, what are other possible options to house all related information about a Genetics test? Could the Regions Studied resource be expanded further to house this kind of information? SampleReportTemplateAllPositiveforgForge.docx
More info from @Larry Babb
Each of the highlighted numbered items in the Methodologies and Test Limitations section on pages 5-6 could be considered separate test methodologies that produce results that are used for subsequent methods and analytic results. It seems that the ServiceRequest is one way to codify these methodologies, but it is not clear specifically how to deal with the complexity and also link it to the specific observations that result from each assay's methods.
Another approach may be to use loinc codes (in the Observations) to define the specific question being answered by the result. If we are to create/define LOINC codes that represent the specific methods/assays that might work, but it is not clear that is a reasonable approach.
We may be able to consider this report a composite report made up of 3 smaller reports. If so, then it may be worth exploring the notion of nested DiagnosticReports. However, it is not clear whehter this would hold up for all genetic testing result scenarios. It is also not clear whether HL7 FHIR supports the notion of composite reporting.
Details also in the gforge tracking item #19827,
Kevin Power (Mar 07 2019 at 14:45):
We do have the Region Studied profile as a starting point. And some can be conveyed in Observation.method. Otherwise, do you feel this sort of information needs to be shared in a discrete and computable fashion? What do you think the downstream systems would do with this computable data? Including it in the body of the report is still an option, but of course is not computable.
Bret H (Mar 08 2019 at 14:14):
is the reference information 'canned' Meaning is the reference information you are intending to send about the methodology and not likely to change?
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 08 2019 at 20:48):
The CAP/CLIA Disclaimer language is usually canned, required for accreditation/CLIA, but usually the same across all test results to which it pertains.
Will Defer to @Mullai Murugan on their practice, but anything that is repetitive (report section, test panel, canned comments, etc.) should be able to be consistently structured in it's own block so the block can be added in for each patient for consistency, etc. Looks like the color coded report sections achieve that in the Sample Word Report.
Mullai Murugan (Mar 09 2019 at 14:56):
@Kevin Power @Bret H @Andrea Pitkus, PhD, MLS(ASCP)CM, CSM the CAP/CLIA language is canned for all tests while the test info, methodology and references are canned by test. This information generally does not need to be computed and is more for consumption by the end user of the report.
Though it is not currently represented in the sample report provided, what we would ideally like to have is test info and methodology etc. that is common to the entire test/report but have a way to distinguish methodology for each panel - the wet lab sequencing methodology is the same for all three components of the test i.e. gene panel, prs, and pgx but the bioinformatics methodology is different for each of these components (as mentioned by @Larry Babb ).
Referencing FHIR representation .... stream, if we implement the concept of a top level diagnostic report for the entire test with sub diagnostic reports for each panel, one possible option might be to include this kind of information in the DR itself? Or a related Observation similar to the current draft but expand it further to house more info? What are your thoughts?
Kevin Power (Mar 09 2019 at 17:50):
if we implement the concept of a top level diagnostic report for the entire test with sub diagnostic reports for each panel, one possible option might be to include this kind of information in the DR itself? Or a related Observation similar to the current draft but expand it further to house more info? What are your thoughts?
I think it goes back to computability. I think it would be helpful to see the kind of info you are talking about, along with your sense of what might be important to be discrete/computable, versus what is OK simply being on the body of the report, which will always come along with the DiagnosticReport.
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 11 2019 at 13:47):
Concur with 1st paragraph. For 2nd, would like to see what you are describing modeled out. There would be the outer structure/backbone with the required CAP/CLIA info, followed by "modular" sections following the CG implementation guide, but would be helpful to find out where gaps remain to model the information. Assumes all the results described are sent in the DR at the same time. If some are addended or amended, would need to know that too. Of course, that varies on laboratory practice/test menu offerings (if certain things are sent to reference labs, etc.) @Kevin Power has been describing "nested" reports or multiple reports in DR as well. It should be easy for any lab to report genetics info with a single integrated report.
Bret H (Nov 10 2021 at 16:38):
FYI: https://confluence.hl7.org/display/FHIR/Order+Catalog+FHIR+IG+Proposal looks relevant to this thread
Last updated: Apr 12 2022 at 19:14 UTC
