Stream: Orders and Observation WG
Topic: GF#15521
Eric Haas (May 01 2018 at 15:58):
GF#15521 Add+%22supportingInformation%22+as+either+a+core+element+or+standard+extension+to+DiagnosticReport :
I can see a use for this but would like to find out whether is a real implementation need or windowdressing for completeness sake. Is this typically all glommed together in the DR conclusion as free text or in DR.presentedForm.
Eric Haas (May 01 2018 at 15:59):
Specific use cases sought...
Grahame Grieve (May 05 2018 at 04:41):
I've only ever seen supporting information on the request. WHich is right where we have it
Lloyd McKenzie (May 05 2018 at 11:51):
Supporting information on the request lets you send (or call attention to) extra information that might be used when processing the request. Supporting information on the response allows you to identify what information was used in the generation of the report and where adjustements to/refuting of that supporting information might call into question the report results. It may be that it's redundant some times in that if you properly assert "derived from" relationships with all the leaf-level Observations, that would cover many of the situations. But if the person generating the report relied on assertions that the patient had particular conditions, had particular family relationships, etc., there's no way to establish that linkage without adding DiagnosticReport.supportingInfo.
Eric Haas (May 07 2018 at 14:24):
My question is whether it is a " gee wouldn't it be great if we could do this" vs what capabilities do implementers need now. I'm not getting a lot of supporting information for adding it in.
Lloyd McKenzie (May 07 2018 at 14:28):
I'm fine with it being a standard extension
Eric Haas (May 08 2018 at 18:38):
OO on FHIR call, EH moves to make standard extension, second: JCT : 4-0-1 (RH Chair) ( move notes to jira)
Eric Haas (Jul 18 2018 at 10:21):
@Lloyd how does this request differ from adding an element for citations using relatedArtifact. GF#15824 I think Supporting information would already cover this, why is there a need for both?
Lloyd McKenzie (Jul 18 2018 at 14:47):
RelatedArtifact lets you point to literature - journal articles, papers, research studies, etc. that provide evidence for the results or guidance on how to interpret the results. supportingInformation indicates information from the patient's record that was taken into account or used to help calculate the results. They're rather different things.
Eric Haas (Jul 18 2018 at 16:07):
if I made a Venn diagram SupportingInfo does everything RelatedArtifact does. 7-18-2018-9-03-42-AM.gif
Eric Haas (Jul 18 2018 at 16:15):
No need for both. They are even described using the say terms in the trackers.
SupportingInfo tracker:
"Details (Edit)
When returning a diagnostic report, it's not uncommon to reference "other" information that was not generated as part of the diagnostic process that was either used by the lab in making their determination or is provided to the ordering clinician to help with their interpretation of the results. In genomics, this can include family history, other observations about the patient and literature references."
relatedInfo Tracker:
"Details (Edit)
The RelatedArtifact data type allows conveying citations, supporting evidence, documentation of processes, caveats around testing methodology and other supporting documentation relevant to a resource. This information is commonly included as references as part of laboratory and clinical genomics reports. As such, it should be supported by Observation, at least as an extension."
Eric Haas (Jul 18 2018 at 16:16):
can reference directly using Binary in supporting information too
Eric Haas (Jul 18 2018 at 16:22):
So my impression is supportingInfo is the grab grab .everybody is clamoring for so they don't have to worry about context. Just dump a bunch of references in there and let the data consumer figure out the how it relate to the Observation or DiagnosticReport. @Brian Reinhold ?? and @Alexander Henket ?? Why even have any other elements? just code- value-supportingInfo
Eric Haas (Jul 18 2018 at 16:25):
On a less rhetorical note it is getting increasingly difficult to provide guidance for what to use when as we try to create new ways to reference yet another resource. Which why I am reluctant to add another extension for relatedArtifact. Just (over)use supportingInfo instead....
Lloyd McKenzie (Jul 18 2018 at 18:31):
Understand the concern. RelatedArtifact gives a deeper structure that's appropriate for literature-type references that supportingInfo doesn't provide though.
Alexander Henket (Jul 19 2018 at 05:30):
I’m not sure what the discussion has evolved into but since Eric mentioned me I guess I’ll reiterate my request:
- result of breathing test was obtained while/after “administering extra oxygen”
And yes sure there is a heap of things that can help determine context. My microbiologists kept the use cases coming. And yes that might not be recorded as structured as you would like. I blame the real world for that.
Eric Haas (Jul 19 2018 at 15:30):
@Alexander Henket I have a proposal for your tracker which is closely related to @Lloyd McKenzie and @Brian Reinhold trackerrs and I'm having difficulty thinking we need all these different ways to do essentially the same thing and heartburn trying to describe how to use one verses the other.
Like I say in my proposed disposition for your tracker "result of breathing test was obtained while/after “administering extra oxygen" you can skin this cat about 6 different ways:
- with terminology using pre-coordinated or post-coordinated concepts, using translations in
code - or structurally using components or like you want a new extension (for now) to reference a qualifying or refining Observation....
Observation has devolved into a multipurpose name:value resource which can meet the needs of all and none at the same time - it is great for flexibility and really crappy for interoperability. You will always need to profile it. (I think I'll change the resource introduction to this ;-) )
Eric Haas (Jul 19 2018 at 15:39):
After thinking about this I changing my answer and proposing :
1. GF#15824 NeedRelatedArtifactonObservationandDiagnosticReport (Lloyd McKenzie) : not persuasive see use SupportingInfo
2. GF#17228 SupportinginformationinObservation (Alexander Henket) : Persuasive/Mod add extension (for R4) SupportingInfo which covers all the gaps in referencing whatever you want for whatever reason you want that is not covered by an existing element.
3. GF#16172 Observation.derivedFrom%2FhasMember (Brian Reinhold) In Person : Persuasive/Mod add extension (for R4) SupportingInfo which covers all the gaps in referencing whatever you want for whatever reason you want that is not covered by an existing element.
Lloyd McKenzie (Jul 19 2018 at 15:46):
supportingInfo and RelatedArtifact are not the same thing. You can't say the same things with them. RelatedArtifact allows you to point to literature, convey citations, relationship types, etc. supportingInfo is just a linkage to what resources were used (or are to be used) to perform an action.
Lloyd McKenzie (Jul 19 2018 at 15:47):
I accept that the boundaries may need to be made more clear, but that doesn't mean that both aren't needed.
Eric Haas (Jul 19 2018 at 15:58):
If relatedArtifact were loosened up a bit it to include a Reference(Any) and more types and tweek to the definition it could replace all this and more ( and we would go full circle back to related...) it would be like a supportinfo on steriods...
Eric Haas (Jul 19 2018 at 15:59):
In other words replace related with a related type metadataelement superRelatedArtifact
Alexander Henket (Jul 19 2018 at 16:03):
We landed on extension because Observation is so close to normative and we felt enough uncomfortable to postpone new breaking changes. If more sort of similar use cases pop up I’m fine with anything that carries the right semantics. My use case involved a procedure with device characteristics so a simple CodeableConcept wouldn’t do
Lloyd McKenzie (Jul 19 2018 at 17:33):
RelatedInformation isn't intended to be supportinInformation on steroids. It's intended to provide literature links, ties to other protocols, etc. It's about accademic provenance. What I'd actually prefer is for it to be more tightly defined so that it's very clear how it and supportingInfo are distinct. @Bryn Rhodes ?
Bryn Rhodes (Jul 19 2018 at 17:35):
Agreed, RelatedArtifact is a definitional component, I wouldn't expect to ever see a reference to patient-specific information in a RelatedArtifact.
Bryn Rhodes (Jul 19 2018 at 17:36):
I think that's potentially a reasonable boundary condition. Supporting Information is about what patient resources support a particular observation, RelatedArtifact is about what knowledge resources support it.
Lloyd McKenzie (Jul 19 2018 at 17:42):
I like that boundary.
Eric Haas (Jul 19 2018 at 18:12):
-
Why limit relatedArtifact to definitional space- why exclude patient-specific information? I mean it seems to handle the use cases for pulling in other FHIR and nonFHIR resources pretty comprehensively and we have gotten numerous trackers to do just that ( reference other stuff ).
-
What we talked about in OO is keeping the STU3
relatedand it instead of a bunch of elements and extensions making it a single reference to a new improved relatedArtifact-like meta element that could handle all this stuff. What we ran into with related was meshing the type code with the Reference[Type]. That does go not away with this new improved relatedArtifact-like meta element, but why do we care at the base level? Let implementers do what they want and create there own constraints of Reference([Type]). It is no better or worse than having something like suppportingInfo Reference(Any) and more consistent approach.
Lloyd McKenzie (Jul 19 2018 at 19:16):
Because all of the places it's used, that's what it's for
Lloyd McKenzie (Jul 19 2018 at 19:17):
RelatedArtifact is for provenance information for protocols, decision support rules, data models, etc. All of the extra properties in it are tuned to that purpose.
Lloyd McKenzie (Jul 19 2018 at 19:17):
When we want to send the height or weight along with a prescription or lab result, it's overkill and inappropriate
Lloyd McKenzie (Jul 19 2018 at 19:17):
There's no reason to try to collapse the use-cases or the data structures
Eric Haas (Jul 19 2018 at 19:26):
except the onesy twosy trackers are overwhelming me
Eric Haas (Jul 19 2018 at 19:27):
they are asking for essentially the same thing with a slightly different context.
Eric Haas (Jul 19 2018 at 19:30):
I disagree it is overkill - over the wire is no more than related in STU3. and from your first response it is apparent relatedArtifact was created without consideration for broader use, I am suggesting that maybe it is appropriate for the broader use case as well.
Lloyd McKenzie (Jul 19 2018 at 19:35):
We don't RelatedPerson to support broader use. The places it appears are specifically places where only definitional resources are appropriate. Opening it up to non-definitional resources would be a signficant problem.
Eric Haas (Jul 19 2018 at 20:03):
I don't understand fundamentally, why would it be a problem - I you want to use it definitionally then you restrict the references to definition resources? can you explain?
Lloyd McKenzie (Jul 19 2018 at 20:57):
In resources, we can't restrict the references. When we reference the type, we get the full type - unconstrained.
Jack Wallace (Jul 19 2018 at 21:55):
Semantically, the name "relatedArtifact" doesn't imply anything about it being specific to citations. In English, it would be interpreted as an artifact that is related to the resource it appears in. A citation appearing in a resource could certainly be "supporting" why something was done, or is to be done. The name "supportingInfo" doesn't imply that a citation would be out of place. In English, it would be interpreted as information that is supporting why something was done or is to be done or even what is to be done. So semantically, they sure appear to be covering the same ground. And semantics are important since 99% of implementers are not going to have the extensive background or experience in why FHIR resource are the way the are and how they are supposed to be used like a Lloyd or Eric or Grahame, and are going to rely on the semantics of resource and element names, and secondarily are going to look at the definitions and scope; not perfect, but how implementers work.
Structurally there is the same confusion. supportingInfo is a reference to "Any", and RelatedArtifact includes a reference to "Any". So again, they really seem to be covering the same ground
I am not aware of any resources that include both supportingInfo and RelatedArtifact, and if we did that would cause a ton of confusion with implementers. But it just seems odd to me to have 2 things that are semantically the same, and sometimes we use one and sometimes we use the other.
Lloyd McKenzie (Jul 19 2018 at 22:12):
RelatedArtifact is indeed an overly broad name. I'd be open to constraining that too...
Bryn Rhodes (Jul 19 2018 at 22:21):
I'd be open to that as well, names are hard. We could also constraint RelatedArtifact to be reference(ActivityDefinition|PlanDefinition|Library|...)
Eric Haas (Jul 19 2018 at 22:45):
is already constrained to canonical so that covers it.
Eric Haas (Jul 19 2018 at 22:49):
I'm still not convinced we need both supportingInfo and relatedArtifact in Observation and in FHIR ... I think we keep that name and broaden its scope by smooshing them together. I'm not understanding the downside. The context of use determines what is referenced right?
Grahame Grieve (Jul 19 2018 at 22:55):
are you proposing generally changing RelatedArtifact in all resources?
Eric Haas (Jul 19 2018 at 23:02):
I'm pondering whether:
- changing relatedArtifact to be more used generally which means replacing canoncal with Reference(Any), edit description
- and replace all type Reference(Any) for
[Type].supportingInformation,Observation.relatedtype with it.
Though is a proposal and I'm looking for the downsides.
Grahame Grieve (Jul 19 2018 at 23:03):
so far you've only be interested in the downsides in the scope of Observation, not the downsides in the other contexts it is used
Grahame Grieve (Jul 19 2018 at 23:03):
at least, that's my impression from this topic
Eric Haas (Jul 19 2018 at 23:26):
when I say downsides I mean overall
Grahame Grieve (Jul 19 2018 at 23:28):
well, there's very definite downsides for opening up related artifact to reference anything from the knowledge resources
Eric Haas (Jul 19 2018 at 23:30):
why? Seems like I've been saying the same for Reference(anything) for a long time with Observation and nobody seems to think so.
Grahame Grieve (Jul 19 2018 at 23:36):
Observation is not a knowledge resource.
Grahame Grieve (Jul 19 2018 at 23:36):
that's why I said: "you've only be interested in the downsides in the scope of Observation"
Grahame Grieve (Jul 19 2018 at 23:37):
all the other places where it's used...
Eric Haas (Jul 19 2018 at 23:42):
Yes yes I know where its used, Ignoring Observation - why would it be bad if it were reference (any) where its presently used. One would surmize that the context of use would dictate that it should reference the appropriate FHIR and non-FHIR resources.
Lloyd McKenzie (Jul 19 2018 at 23:42):
In knowledge resources, it's essential that the references can only be to other knowledge resources and we want to convey things like citation information and the type of relationship.
With supportingInfo, we want other clinical information and there's no type of relationship involved other than "supported/will support execution of the event"
Lloyd McKenzie (Jul 19 2018 at 23:42):
Knowledge resources can't represent patient-specific resources. That would be a very bad thing.
Eric Haas (Jul 19 2018 at 23:42):
There is no such constraints on the nonFHIR resources it may reference.
Eric Haas (Jul 19 2018 at 23:43):
just words ...
Lloyd McKenzie (Jul 19 2018 at 23:43):
Right. So we agree there should be such constraints.
Eric Haas (Jul 19 2018 at 23:51):
OK back to Observation too many extensions, too many options to do the same thing, too many opportunities to do it wrongly like using supportingInfo Reference(Any) to list all the members of a panel, the patient, the Device, the Procedure......
Eric Haas (Jul 19 2018 at 23:53):
... and documentation, and citations.
Eric Haas (Jul 19 2018 at 23:54):
but I don't think those last two are wrong
Lloyd McKenzie (Jul 19 2018 at 23:57):
You could stick everything into an annotation too. And I'm sure someone will try. That doesn't mean we don't create distinct elements for things with clearly different purposes. Agree that the definition for supportingInfo should clearly exclude the use-cases for Related if we add it. There should be a clear location for different things.
Grahame Grieve (Jul 20 2018 at 00:35):
but back to a point Lloyd may be familiar with... can existing systems differentiate between these things? How would they be represented in v2?
Grahame Grieve (Jul 20 2018 at 00:35):
btw, shouldn't this stuff be extensions so we can see how this plays out before adding to Observation?
Lloyd McKenzie (Jul 20 2018 at 01:01):
Yup - we're only talking about extensions.
Lloyd McKenzie (Jul 20 2018 at 01:02):
And supporting RelatedArtifact is a particularly advanced piece of functionality. If the differentiator is patient-related vs. not, presumably systems can do that.
Grahame Grieve (Jul 20 2018 at 01:04):
I'd be surprised. certainly the lab system I used to be CTO for wouldn't. All we had was a text string that might be a reference to... something.....
Lloyd McKenzie (Jul 20 2018 at 01:08):
Then that'd have to go into notes. If you don't have a reference or a URI, you can't use either of these extensions.
Eric Haas (Jul 20 2018 at 01:40):
OK waving the white flag , I've been convinced reluctantly to add three new extensions. ( the third is qualifiedBy which wasn't added before when removed .related but Alex's tracker fit this use case and is certainly not supporting information.) I will need to beef up the definition of supportingInfo reference(Any)
Bryn Rhodes (Jul 22 2018 at 20:40):
Looking at RelatedArtifact, it's actually using a canonical, so it's already the case that it can only point at KnowledgeResources. It does use "canonical(Any)" though, should that be just "canonical", or is the "Any" in this context understood to be "Any resource referenceable by a canonical URL"?
Lloyd McKenzie (Jul 22 2018 at 20:45):
Any would need to be any resource referencable with a canonical URL - but probably worth a clarification of the spec to make that explicit
Bryn Rhodes (Jul 22 2018 at 20:55):
Last updated: Apr 12 2022 at 19:14 UTC
