Stream: Orders and Observation WG
Topic: report disclaimer
Larry Babb (Sep 03 2019 at 18:27):
Is there a way to include "disclaimer" text on a DiagnosticReport? We are planning on following the model provided by the Measure resource to include an extension that is a first class attribute called disclaimer that is of type markdown.
Can anyone weigh in on whether this is reasonable or not?
Lloyd McKenzie (Sep 03 2019 at 18:35):
FHIR-I has had some discussion about whether 'disclaimer' should be separated from the legal text that's typically sent in 'copyright' - so it's possible that Measure.disclaimer will go away. However, DiagnosticReport doesn't have a "copyright" element, so an extension seems reasonable.
Eric Haas (Sep 03 2019 at 19:04):
A cover your ass extension could be on any resource. Why hasn't this come up before?- seems like a pretty common desire. Does this fall under Security labels: as in: 'The use limitation on a data Bundle' : http://build.fhir.org/security-labels.html#core ? @John Moehrke ?
Eric Haas (Sep 03 2019 at 19:05):
or is this typically handled in the overall business arrangement between systems as general disclaimer? ConformanceStatement? or http headers?
John Moehrke (Sep 03 2019 at 19:17):
There are security tags that can be used to express a bunch of things. But if you don't know the recipient is going to look at those tags, understand your vocabulary, AND abide by them... then you are just writing a wish in the sand.
John Moehrke (Sep 03 2019 at 19:19):
This is a reality of ANYTHING... right? If someone does not understand what the LOINC code 35094-2 means, then you are NOT communicating to that recipient a blood pressure.
John Moehrke (Sep 03 2019 at 19:20):
Thus there tends to always need to be some over-arching policy that assures that participants understand LOINC codes for medical observations, and understand a sub-set of security tags for use of security tagging
John Moehrke (Sep 03 2019 at 19:20):
back to Lloyds point about a CapabilityStatement... I am sure that this is a nice technical solution, but don't think that this would be seen as a realistic solution in a court...
Grahame Grieve (Sep 03 2019 at 19:21):
Lloyds point about a CapabilityStatement
? which was
John Moehrke (Sep 03 2019 at 19:26):
I was understanding the proposal that in the CapabilityStatement published by the Server could be disclaimer statements. These could be in there, but I don't think they protect the server from clients that don't read these disclaimers and do stupid stuff anyway. I agree with the statements that there really needs to be a user-interface that stresses disclaimer like statements... I am not a lawyer.
Grahame Grieve (Sep 03 2019 at 19:27):
I don't think there was any connection to CapabilityStatement there
Eric Haas (Sep 03 2019 at 19:28):
It was on another stream:https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Legal.20Implications.20Operating.20a.20FHIR.20Server.20Test.20Instance
Eric Haas (Sep 03 2019 at 19:29):
you mention that you put GPDR in the header and something about Capstatements
Eric Haas (Sep 03 2019 at 19:29):
which is why I asked here... I am just asking since I am well out of my depth on this topic
Grahame Grieve (Sep 03 2019 at 19:30):
wooah that was obscure! in general, capability statements/headers are relevant for GDPR but irrelevant for a disclaimer on a DR
Eric Haas (Sep 03 2019 at 19:32):
Why can't you say in your capstatement that you are in no way liable for yada yada yada?
Eric Haas (Sep 03 2019 at 19:32):
a blanket CYA
John Moehrke (Sep 03 2019 at 19:33):
You can say it. I am just asserting that you saying it doesnt mean it helps you in any legal way
Eric Haas (Sep 03 2019 at 19:33):
so is it any better saying on a resource by resource basis?
John Moehrke (Sep 03 2019 at 19:33):
nope
Eric Haas (Sep 03 2019 at 19:34):
:-)
John Moehrke (Sep 03 2019 at 19:34):
which is likely the leap that I made that I didn't express
John Moehrke (Sep 03 2019 at 19:35):
In practical use, there is an overaching policy that participants agree to that states things like disclaimers and vocabulary expectations.
Lloyd McKenzie (Sep 03 2019 at 20:02):
Disclaimers on a DR wouldn't be covered by CapabilityStatement. The DR disclaimers are typically going to be specific to the particular testing performed and methodology used. The caveats around a blood pressure would be quite different from those around genetic testing.
Eric Haas (Sep 04 2019 at 00:29):
Those are a note or comment.
Eric Haas (Sep 04 2019 at 00:29):
And not specifically a disclaimers
Eric Haas (Sep 04 2019 at 00:30):
At least when I read labs there are no disclaimers
Lloyd McKenzie (Sep 04 2019 at 00:31):
There are for genetic results, I think - which is where this is coming from. I can conceive of disclaimers for 'cheap/fast' variants of lab tests too, but no clue if it happens
Mullai Murugan (Sep 05 2019 at 12:59):
Screen-Shot-2019-09-05-at-7.57.30-AM.png
We are a genetic diagnostic lab and attached is an example of our disclaimer.
John Moehrke (Sep 05 2019 at 14:17):
Where do you put this disclaimer? Is it just on a human readable web-page, is it in the FHIR CapabilityStatement, is it in every Resource.text element, other?
Eric Haas (Sep 05 2019 at 15:17):
thats look like a note to me.
Eric Haas (Sep 05 2019 at 15:18):
NTE in V2 speak
Eric Haas (Sep 05 2019 at 15:20):
so either note element or another observation
Eric Haas (Sep 05 2019 at 15:24):
or an disclaimer extension...mmmm again is a choice between lumping in more general structure or create more specific elements. Like Lloyd said we talked about a "terms of use" type element for things like valuesets etc. I'm starting to lean towards a generic extension that could cover all this. Which means we trudge back to FHIR I and reconsider that tracker.
Eric Haas (Sep 05 2019 at 15:26):
we have copyright elements in valuesets and this kind of a similar concept and that is what I am basing this on.
Eric Haas (Sep 05 2019 at 15:26):
@Lloyd McKenzie ?
Lloyd McKenzie (Sep 05 2019 at 15:46):
The real question is whether this is something we expect to exist beyond Observation. Within Observation, it can be a component. (It's not really something that's stand-alone). But if you were to make similar statements about DiagnosticReport, RiskAssessment and other things, then you start to need an element/extension - and consistency across resources is nice. Measure already has an explicit element.
Mullai Murugan (Sep 17 2019 at 22:15):
Two options for our disclaimer are the DiagnosticReport resource or the PlanDefinition that is referenced from the Filler based ServiceRequest. Re @Eric Haas 's comment, if this is a generic extension, then it is might be helpful to have some kind of type attribute to classify as disclaimer, terms or use, copyright etc.
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 30 2020 at 11:48):
It hasn't come up as a full complex path or genomics report likely hasn't been completely modeled accurately in FHIR. Many Lab Developed Tests (LDTs) or even those from more manual benches have "disclaimers" required by CLIA. These must be supported. It's not a security label. They can easily be supported as an observation. They would support the needs @Larry Babb is describing. They are not limited to genomics reporting, but used across various esoteric lab tests. Recommend actual reports be modeled in FHIR to ensure everyone has all the data elements they need and we have a standardized way of representing to achieve interoperability.
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 30 2020 at 11:50):
Which types of "labs" are you reading? They are common for esoteric testing, but not usually in routine panels on analyzers.
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 30 2020 at 11:52):
The common report disclaimer @Mullai Murugan provided is required (per regulatory) as part of the diagnostic report issued by the performing laboratory.
Last updated: Apr 12 2022 at 19:14 UTC
