Stream: genomics
Topic: performing lab disclaimers
Larry Babb (Aug 20 2019 at 12:55):
Does anyone have examples or guidance on how/where to structure the "disclaimer" text this is commonly placed on genetic test result reports? Here's an example from the two labs that are involved in the emerge study. But this text or something very similar can also be found in clinical test results as well.
example disclaimers found on clinical genetic test results for lab-defined tests (a common practice in the industry and allowed by the FDA)
This test was developed and its performance characteristics determined by the Laboratory for Molecular Medicine at Partners HealthCare Personalized Medicine (LMM, 65 Landsdowne St, Cambridge, MA 02139; 617-768-8500; CLIA#22D1005307). It has not been cleared or approved by the U.S. Food and Drug Administration (FDA). The FDA has determined that such clearance or approval is not necessary.
or
This test was developed and its performance determined by this laboratory. It has not been cleared or approved by U.S. Food and Drug Administration. Since FDA is not required for clinical use of this test, this laboratory has established and validated the test's accuracy and precision, pursuant to the requirement of CLIA '88. This laboratory is licensed and/or accredited under CLIA and CAP (CAP# 8004250 / CLIA# 45D2027450).
Since the clinical tests provided by emerge (and many clinical testing labs) are defined and validated by the labs themselves, we have opted to use the PlanDefinition Resource under the ServiceRequest.instantiateCanonical reference to precisely share the performing lab's description and methodology steps (as actions). While this is a reasonable solution to the conundrum surrounding the sharing of genetic test definitions for results, it still is unclear where something like a legal disclaimer should reside in this structure (or anywhere in the DR substructure).
Kevin Power (Aug 20 2019 at 13:03):
I would assume this would always be in the body of the report - Is there a need to have this more discrete than that?
Larry Babb (Aug 20 2019 at 13:14):
In the body of the "narrative" report? So not ever in a structured way that an downstream system could reference it ? I could certainly do that. But, during this emerge effort it has becoming increasingly clear that many of the statements or component parts of the narrative report have importance and "should" be computationally available.
We would like to be able to provide the downstream consumers of a DR to be able to reference these text blocks for use in re-display of the information without loosing context.
In the case of this disclaimer text it can appear at different places on reports (at the end of the test description/methodology section at the footer of the report). This particular block of text is a legal requirement and has some significance as compared to notes and comments.
I'm thinking I'll stick this block of text in the "ServiceRequest.supportingInfo". While that is not ideal, it seems to be an okay place to put it. We can tell our downstream users that it will be there if they need to reference or redisplay it in a different clinical system.
(i digress)
Actually, this does raise a more general question in understanding the aims of the DR effort behind the CG implementation guide. Is the intention of structuring and sharing this data so that the downstream systems can computationally understand the entire context of the result or only portions (results) without the surrounding context that is often embedded in the test definitions and related information returned alongside the results?
I often find that when I consider how/if a downstream system has a complete enough set of contextual data from the result to use it, the answer is no. At least not without some considerably broad assumptions or use of generic and highly standardized codes for both testing and resulting. These just are not available for the types of genetic testing practices taking place in the HTS world IMO.
Kevin Power (Aug 20 2019 at 13:27):
I wasn't saying we couldn't make it more discrete, I was just clarifying that is what you were thinking. To be honest, we haven't considered this in any detail so far, so the short term of using ServiceRequest.supportingInfo seems like a good place to start. Unless this is another place you can use the related artifact extension?
I would say our primary goal has been to identify the data elements within a report that are the most critical parts to have as discrete information. To date, and to no surprise, our efforts have heavily focused on the "result" side of ledger, and much less on the request / definition / methodology (much like the rest of FHIR). While we still have some work to do on the result side I am sure, I think we need some design sessions to really think through how to appropriately structure the other.
Larry Babb (Aug 20 2019 at 13:32):
Thanks. sorry if I came across as cheeky ;). I think I will use the Related Artifact extension on the DR instead (with the "documentation" type) and simply put the text in the "display". That will be more prominent versus burying it in the ServiceRequest. Thanks.
Bret H (Aug 21 2019 at 03:32):
totally seems like we need a structured Test methodology profile. You don't see it being asked for with things like Chemistry panels. You do get reference ranges, but the methodology is basically assumed sound.
Kevin Power (Aug 21 2019 at 03:35):
Do you mean it’s own profile? Or additional profiling on our existing profiles?
Jamie Jones (Aug 21 2019 at 13:59):
A separate Observation to encode the test methods? Similar to region studied but different enough to be separate, I'd wager
Bob Milius (Aug 27 2019 at 17:54):
It seems to me that the disclaimer is part the of the results of the test, not the request to the lab to perform it. If I were ordering a test, I wouldn't put a disclaimer into it. Regarding methodology, perhaps it's time to profile the Device and DeviceDefinition resources for genomics tooling. And, can Procedure be used to describe methodology?
Bret H (Sep 19 2019 at 14:26):
observationDefinition too perhaps
Last updated: Apr 12 2022 at 19:14 UTC
