Stream: genomics / eMerge Pilot
Topic: Report Sections
Larry Babb (May 07 2019 at 23:49):
The genetic test results for LDTs (lab developed tests) based on sequencing assays seem to have a common need to provide a mechanism to share the report sections (methodology, recommendations, gene coverage, disclaimers, background, etc..). While many of these sections have some variation in terms of titles and organization, there is a reasonable amount of commonality. The Composition Resource seems like it is flexible enough to handle both section and associated results, in addition it would enable the nesting of more complex report sections. Diagnostic Report is much more structure which works well when tests are well coded and standardized.
Is it possible or reasonable to consider using Composition and its section for LDTs or less well standardized genetic testing reports in lieu of the Diagnostic Report?
If Diagnostic Report is the best/only choice then is it possible to devise/add a BackboneElement that works similar to the Section element in the Composition Resource? It would be extremely helpful to have a mechanism to pass the section/sub-sections their titles and entries without having to force them into the less natural structure of the DR.
Please advise.
Lloyd McKenzie (May 08 2019 at 00:09):
In general, Composition (and FHIR documents in general) are intended to provide a way to present and navigate information, but should never be the sole way of sharing information. I.e. if you want to share a genomic report as a document (where you have tight control over the names, ordering and rendering of sections), you absolutely can. However, it should be possible for someone to get the same clinical information (less the control on rendering and order of presentation) by querying the resources that the document sections would point to. No one should ever have to use documents (any more than they have to use REST or messaging).
Kevin Power (May 08 2019 at 13:53):
Given Lloyd's guidance on Composition, I think this is a great question / request to direct to O&O.
If Diagnostic Report is the best/only choice then is it possible to devise/add a BackboneElement that works similar to the Section element in the Composition Resource? It would be extremely helpful to have a mechanism to pass the section/sub-sections their titles and entries without having to force them into the less natural structure of the DR.
Patrick Werner (May 08 2019 at 14:53):
will try to ask during joined meeting with O&O
Patrick Werner (May 08 2019 at 15:26):
Asked in O&O:
- If you want to have named sections, the way to go is a FHIR Document with Composition. These Sections don't add semantical meaning, they are just there to group the document.
- you can profile an Observation in order to contain only text to transport the narrative.
- we could have multiple DiagnosticReports for every "section" and one parent report (linked with the summary-of Extension)
Lloyd McKenzie (May 08 2019 at 19:55):
Right. So Observation actually contains the content - and defines what it is - essentially naming it. Composition lets you give a context-specific ordering and context-specific label above and beyond what's conveyed by the Observation.code.
Larry Babb (May 09 2019 at 11:12):
Thanks @Lloyd McKenzie . This does clarify the distinction. So, I really need the DR that the CG is drafting to be able to "get the same clinical information by querying resources that the (emerge) document sections would point to."
To me this verifies the need for much stronger test/assay definitional data sharing for lab developed tests (LDTs). LDTs are quite prevalent in the clinical genetic testing community and hold clinically significant data needed to put the context of the findings in perspective. In addition, it could be argued by the labs providing the report that all of the content on the report including the disclaimers, background and recommendations/comments and additional notes are important contributors to the clinical information.
It is my observation in studying the CG DR profile to this point that some of these elements are missing and it is unclear how to best organize and structure it so we can "...get the same clinical information (conveyed by the report sections) by querying resources...". I think this is why it feels like it would be a quicker path to using Composition and then supplementing it with section.entry(ies) that point to the resources that can provide the clinical information.
Since I need to move more quickly than the CG group can, I am at a crossroads on how to handle this. But your feedback has been very helpful in clarifying the options - difficult as they may be.
Larry Babb (May 09 2019 at 11:28):
OK. It seems like the path is to put the LDT section information into separate Observation profiles. I was taking the route of creating Narrative extensions and being able to attach them to either DRs or OBSs. Even though the section methodologies, background, disclaimers, etc.. are all identical for every occurrence of the performed service I will look into treating them as Observations and thus consider them "results" for the Report of "hasMembers" for sub observations (if I need report nesting). Does that sound right based on the above?
Lloyd McKenzie (May 09 2019 at 16:07):
There are a few possibilities:
1. Observation (and/or DiagnositicReport) use the 'instantiates' relationship to point to the 'lab protocol' that contains all of the definitional and methodology information associated with the test(s). This could be an instantiatesCanonical pointing to a FHIR PlanDefinition or could be an instantiatesUri pointing to a PDF or web page. (Note that 'instantiates' is currently an extension for DR and Obs.)
2. Observation (and/or DiagnosticReport) use the relatedArtifact extension to point to a document (Binary or DocumentReference) or to contain inline descriptive content that "documents" the DR/Obs
3. Create Observations that are part of or have a focus of the Observation or DiagnosticReport that provides additional documentation about those. (Trick here is that 'subject' generally can't be 0..*, so hasMember might work better). The semantics of this approach are somewhat weak/questionable
4. Create specific extensions for this purpose. (Less preferred unless we're confident that the extensions for #1 and #2 are inappropriate/unworkable.
Kevin Power (May 09 2019 at 22:37):
This option gets my vote as long as it works for @Larry Babb and @Mullai Murugan ?
2. Observation (and/or DiagnosticReport) use the relatedArtifact extension to point to a document (Binary or DocumentReference) or to contain inline descriptive content that "documents" the DR/Obs
Larry Babb (Sep 02 2019 at 02:20):
@Lloyd McKenzie based on your recommendation back on May 09 above, we are trying to work through the use of PlanDefinition with the instantiatesCanonical to describe and share the 'lab protocol' to contain the definitional and methodology information associated with the performed test(s).
We really appreciate your guidance and could use some assistance with the 3 follow-up questions.
I do not see the 'instantiates' relationship on the DiagnosticReport. I'm not sure it makes sense on the Observation. We did find it on the ServiceRequest.
Q1: Should we hang this PlanDefinition to describe the 'lab protocol' performed off of the ServiceRequest? If not, can you guide us on where we should hang this and if we should use an extension to do so?
The actual way the emerge orders work is that the lab defines the order and the order's reference it. There is no definitional or order# that is managed and controlled by the ordering provider systems.
Q2: If we should use the ServiceRequest.instantiatesCanoncal(PlanDefinition) do I presume that the ServiceRequest itself represents the Filler's servicerequest and not the Order's?
The PlanDefinition.type is a codeableconcept and has several terms, I'm not sure which one is appropriate. Here's the valueset. The definition of these terms seem to be focused on the clinical procedures which do not necessarily align with lab protocols or procedures.
Q3: Could you recommend the correct type? Should we provide our own - possibly called 'lab-protocol'?
Lloyd McKenzie (Sep 02 2019 at 14:42):
Q1. There's an instantiatesCanonical extension on DiagnosticReport. Typically, links happen everywhere they're relevant. So if the order said 'use protocol X' and the diagnostic report and observations were created based on 'protocol X', then all of the resources should point to the protocol. However, if the order didn't say anything about the protocol, then the ServiceRequest shouldn't point to it. You'd just point to it from the 'event' resources.
Q2. The ServiceRequest resource has an 'intent' that allows you to differentiate the placer order from the filler order
Q3. @Bryn Rhodes - your thoughts? I'm not a fan of lab-protocol as it seems too narrow, but it does seem that a technical protocol for conducting tests doesn't really fall inside the others. Lab protocols include things like the sequence in which samples go through machines, how dishes are washed, etc. and have nothing to do with treating a condition. We also have a need for protocols describing how to test that drugs are being manufactured correctly, which seems like the same sort of non-clinical thing.
Bryn Rhodes (Sep 05 2019 at 07:33):
@Larry Babb , @Lloyd McKenzie , we've expanded a bit on some of those definitions in the Clinical Guidelines IG with specific profiles of PlanDefinition (cpg-protocoldefinition, and cpg-workflowdefinition). The distinction we drew between the two was more about the kinds of things you're allowed to say in the actions. Would this be a similar distinction? As in a "technical protocol" would only make use of certain aspects of the PlanDefinition and not others?
Lloyd McKenzie (Sep 05 2019 at 15:38):
@Bryn Rhodes I'm not sure the differences would be in technically what's possible, but more in who'd want to see them and naming. A lab protocol might need the same bells and whistles (ordering, triggers, etc.) as a clinical protocol, but it's not a clinical protocol. I think the real problem is that "clinical-protocol" includes the word "clinical" when "protocol" (with triggers, preconditions and temporal relationships) can happen for all sorts of non-clinical things too.
Bret H (Sep 05 2019 at 15:46):
to Llyod's point, you're refering to problems cause by systems computing using cpg-protocaldefinition right? There could be problems with broadening the scope. Have you looked at the way LIVID defines methods using obsersvationDefinition. It seems to me that there is room in ObservationDefinition to give the lab space to describe their methods and potentially disclaimers. @Bryn Rhodes @Lloyd McKenzie Also, to clarify - one would not need to send the observationDefinition profile each time the lab was reported but only provide a reference link to it (with the caveat that you keep a FHIR server open to deliver it). For @Larry Babb have to look closely at what is relevant to clinical decision making. If the information is static when reporting on the same test - then providing a reference link would be very appropriate. But if the information is really, really critical for the clinician to make an accurate decision for the specific result, then a section makes sense in diagnostic report (see Breast Radiology IG for an example of this approach).
Lloyd McKenzie (Sep 05 2019 at 15:53):
ObservationDefinition won't give you the full protocol - that still needs to be PlanDefinition
Bryn Rhodes (Sep 06 2019 at 03:32):
One thing we've been looking at is adding the notion of a "strategy-definition" as a new type of PlanDefinition that would be a conceptual sequence of steps. Might be appropriate for this use case as well.
Lloyd McKenzie (Sep 06 2019 at 03:47):
A lab protocol, study protocol or genomics pipeline aren't "strategies". They're not conceptual. They're exercised "as written" and are just as concrete as clinical protocols.
Bryn Rhodes (Sep 06 2019 at 05:11):
Except that what we're identifying is the separation between "what" step should be taken, and "how" that step is actually taken in any given setting. I'm not familiar with lab protocols, so maybe it doesn't apply, but for example, when the recommendation is "give the patient a beta blocker", how that actually happens within any given setting will vary to a degree that makes it difficult share a precise description of the intended actions.
Lloyd McKenzie (Sep 06 2019 at 05:24):
I think clinical protocols can have a varying degree of precision. A protocol created at a particular hospital might well identify a specific drug and maybe even a specific clinician who should provide a given therapy. Those defined for general applicability will have more flexibility. Lab protocols and study protocols would operate the same way.
Bryn Rhodes (Sep 06 2019 at 05:29):
So are you suggesting that we should drop the clinical prefix from the clinical-protocol type?
Lloyd McKenzie (Sep 06 2019 at 06:09):
I think that's cleanest. I don't think "clinical" is a useful differentiator
Bryn Rhodes (Sep 06 2019 at 13:25):
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=23876
Bret H (Sep 09 2019 at 15:27):
@Larry Babb for the benefits of others who see this chat, can you summarize what information you will be putting into protocol? "The genetic test results for LDTs (lab developed tests) based on sequencing assays seem to have a common need to provide a mechanism to share the report sections (methodology, recommendations, gene coverage, disclaimers, background, etc..)." something from this? Many thanks!
Larry Babb (Sep 09 2019 at 15:48):
@Bret H My first pass is to use the PlanDefinition for only those items that are strictly defined for a given LDT. There are two sequencing centers (labs) in eMERGE each with a conceptually similar test definition, slightly different methodologies and clinical processes and reporting formats. Each of the labs may have several variations (specializations) of the LDT which could be considered versions or possibly separate tests with similar methodologies.
In any case, I have used the PlanDefinition.action to capture the text of the methodology. We could put the entire text blurb for the whole methodology into one PD.action.description but we are going to suggest they break them up into separate PD.action(s), since they are numbered on the reports.
I am using the PD.name and PD.title for the computer and user-friendly names of the test as defined by the lab, respectively.
It looks like we will use the PD.type = 'protocol' if the tracker item above that Lloyd and Bryn worked out gets completed.
We will use the PD.status = active value.
We DON'T currently know what to do with the "Disclaimer" text blurb that the labs place on their reports. We believe this is test independent, so we are currently planning on building our own custom extension for this off of the DR. (would love some useful ideas on this - it is not an observation IMO and it is important to be able to have downstream systems find and re-display this text to physicians if we want to be able to re-represent the report content in a form other than the PDF.)
Background. for the assay background (or text blurb that summarizes the assay) we are planning on using the PD.purpose field for that. Unfortunately, if we want to have a "background" for a sub-section of the report we'd have to define a more complex PD structure (I think), so that is somewhat limiting and frustrating to figure out. We may end up creating a few custom extensions here and there to fill the gaps where we are not so well informed by all the options and possibilities for organizing the data.
Digression: In the end, there is a real pragmatic concern over the diminishing returns at trying to structure all of this information. Ideally, we'd be able to add "report sections with labels, text blocks and types" somehow so that the Observations could be related to these key human-readable, shared bits of information and thus allow the DR to be structured and re-represented by downstream systems without loosing the context that these sections of the report contain.
Recommendations and Gene Coverage do not fit in PlanDefinition. We actually have sections called Recommendations & Comments that actually are more generic note-like fields to provide proposed or suggested recommendations or information to the physician and/or patient regarding the test and its results. We are moving in the direction of using a standard Observation as a DR result with a LOINC code for "comments" based on the guidance from Lloyd.
For Gene Coverage, we see this as an Observation as well. Although we want to return it as a relatedArtifact because it is in a BED file format and we do not see a pragmatic means for structuring it (it is way outside the scope of what we need to do). The data in the GeneCoverage is very much case specific so it seems like a kind of DR.result (observation). Our current challenge is figuring how to return and artifact/attachment as a result value. (Any suggestions would be welcome).
Hope that helps.
Bret H (Sep 27 2019 at 12:32):
have you looked at http://build.fhir.org/ig/HL7/genomics-reporting/extension-SupportingInfo.html we've placed this in http://build.fhir.org/ig/HL7/genomics-reporting/genomics-report.html It could point to a disclaimer page or static documentation.
Last updated: Apr 12 2022 at 19:14 UTC
