Stream: implementers
Topic: Patient-reported/uncertain data and is-modifiers
Morten Ernebjerg (Nov 22 2018 at 09:29):
I am working on a project in which FHIR-data for a given patient is being exchanged between multiple doctors and the patient herself. Some types of data (e.g. a vital sign) can come from either the patient or a doctor, with the source encoded in the standard way, e.g. in Observation.performer. How a piece of information is handled by doctors (and their clinical systems) can depend strongly on whether it comes from another doctor or the patient. E.g. patient-reported information might be associated with a much lower certaintly (as e.g. the description of Observation.performer explicitly acknowledges) and be classified differently in the clinical system. So although Observation.performer is not an is-modifier, the link with certainty would seem to implicitly move it close to the description of is-modifier property, e.g.
Typical examples of elements that are labeled "Is-Modifier" are elements such as "status", "active", "refuted", or "certainty" that invert or negate the meaning of the resource (or element) that contains them.
My question is how to mark and best handle such implicit uncertainties (patient reported vs. "real medical" information) in fields that are not is-modifers. I also encountered this in the context of an extension which effectively marks some data as being patient-reported - here, the question would be whether (or under what circumstances) such an extension should be a modifier-extension.
Simone Heckmann (Nov 22 2018 at 10:23):
I think patient-reported vs. practitioner-reported is rather a qualifier than a modifier. While certainty per se can be anything from "highly unlikely" to "absolutely certain", a patient reported Information would only lower the probability of the information being correct by a small amount, but never to the point of negation. However, if in a specific scenario like yours, the information of who performed the Observation is very important and should never be ignored by anyone you're exchanging the data with, you might want to mark it as "must-support".
Morten Ernebjerg (Nov 22 2018 at 11:34):
Thanks, a case-by-case- approach sounds sensible given that it is probably a bit of a gray area. On some other resources, there are explicit is-modifier fields for this sort of thing (e.g. Condition.verificationStatus) which is of course nicer than being forced to add a modifier-extension.
Incidentally, I guess a similar question pops up in the context of resources generated by data extraction services :smile:
Yunwei Wang (Nov 22 2018 at 18:54):
Why do you need an externsion to tell if the observation is from patient or not. You can get that from the url pattern of Observation.performer.reference. (eg: patient/xxx vs practitioner/xxx)
Lloyd McKenzie (Nov 22 2018 at 20:39):
There's a difference between "who performed" and "who captured the information in the record".
Lloyd McKenzie (Nov 22 2018 at 20:40):
If a patient reports their HDL cholesterol to a new doctor, the Patient isn't the "performer" of the observation - that would be some unknown lab. They're simply the "reporter" of the Observation.
Yunwei Wang (Nov 22 2018 at 22:58):
What @Morten Ernebjerg mentioned in his first post were those performed by patient self, such as blood pressure.
Morten Ernebjerg (Nov 23 2018 at 11:53):
@Lloyd McKenzie Right, these would be Observation instances reflecting measurements the patient really carried out herself (weight, temperature etc).
@Yunwei Wang The extension I meant is from another context: a certain type of FHIR documents that carry either information provided by the patient or by doctors. Since for our use case these are conceptually distinct, we have an extension capturing that classification.
Lloyd McKenzie (Nov 23 2018 at 15:36):
There's a difference between "performed by" vs. "provided by". Performed by can be captured with the performer. However, if you want to distinguish who provided the information rather than who made the measurement, that requires an extension
Morten Ernebjerg (Nov 26 2018 at 08:28):
Right, that is probably a better way to think about the document extension we have (which may then be a modifier extension if the context makes this information essential).
Eric Haas (Nov 26 2018 at 16:38):
I think you mis-understand what modifier does. It does not mean that it makes some content more important or essential as you stated. It changes the meaning of the parent element. Every element is essential in one context or another. Must support is use to require it and the user ignores something at their peril.
Eric Haas (Nov 26 2018 at 16:43):
Also the element Condition.verificationStatus does the same thing as Observation.status. They are both marked as modifiers since the status ‘entered in error’ nullifies the meaning of the resource. I think Condition.clinicalStatus is not a modifier and the committee whiffed on that one.
Eric Haas (Nov 26 2018 at 16:45):
@Michelle (Moseman) Miller ? Fixing to create a tracker to get rid of the modifier flag on Clinical status. Your thoughts
Morten Ernebjerg (Nov 27 2018 at 14:09):
That was unfortunately a poor formulation on my part: by "context", I meant the specific use-case (associated with specific profiles) not the "runtime context". I just meant to say that the use-case would determine whether a particular extra piece of information needs to profiled in using a modifier extension (namely exactly if that information changes the meaning of the parent element).
Michelle (Moseman) Miller (Nov 28 2018 at 02:36):
@Eric Haas I think Condition.clinicalStatus is gray. On one hand, it doesn't have entered-in-error, which is the default reason why most other statuses are considered modifiers. That said, on the other hand, PC still wanted it to be a modifier since it does have inactive, which is saying that there is no longer evidence of the condition (so it is negating the current presence of the condition).
Eric Haas (Nov 29 2018 at 04:13):
It’s still s patient condition
Michelle (Moseman) Miller (Nov 29 2018 at 13:55):
I don't see an Observation "reporter" extension. I would support one being added, though, since we've (speaking as an implementer now) wrestled with this same question as well. @Morten Ernebjerg are you planning to log a change request asking for a core extension?
John Moehrke (Nov 29 2018 at 14:56):
Patient reported data can also have a Provenance record indicating that it is reported by the Patient.
John Moehrke (Nov 29 2018 at 14:56):
There is also the possibility you can use security tags to indicate the assessed "Integrity" of that data. See the security tags for integrity http://build.fhir.org/v3/SecurityIntegrityObservationValue/vs.html
Drew Torres (Nov 29 2018 at 15:12):
Tag that may be of interest:
UNRELIABLE
http://terminology.hl7.org/CodeSystem/v3-ObservationValue
unreliable
Security metadata observation value used to indicate that the veracity or trustworthiness of an IT resource (data, information object, service, or system capability) for a specified purpose of use is perceived to be or deemed by policy to be inadequate.
Drew Torres (Nov 29 2018 at 15:13):
That is what we are planning on using to highlight patient reported data before an end user reviews the data.
Morten Ernebjerg (Nov 29 2018 at 15:19):
@Michelle (Moseman) Miller We weren't planning to - in our case (for Observation), the key piece of information is that the measurement was performed by the patient, so performeractually does the job. I was mainly just trying to understand whether (and if so, how) one should somehow further flag the fact that data was collected by the patient and hence on a different certainty-level. @John Moehrke @Andrew Torres Thanks for the further options! Given the no. of approaches, I get the feeling this is something that needs to be explicitly settled in each use-case so that clients know what to look for.
John Moehrke (Nov 29 2018 at 15:19):
certainly unreliable might be true, but why not use PATAST which is more specifically identifying that it was patient asserted? Some patients are unreliable, but not all of them
John Moehrke (Nov 29 2018 at 15:20):
yes, a core specification like FHIR needs to provide many possible solutions. An Implementation Guide would define how those using that implementation guide choose to do it the same way.
Drew Torres (Nov 29 2018 at 15:23):
Thanks @John Moehrke! I missed that while skimming the list. I will switch our strategy to leverage that.
René Spronk (Dec 09 2018 at 10:58):
.. which is the better option anyway. For even clinician-reported observations may be considered unreliable/less reliable depending on who made the observation. In general a healthcare practitioner trusts their direct colleagues, and maybe less so when the data was sources from elsewhere (e.g. data recieved from a foreign hospital). As such 'reliability' is in the eye of the beholder. Much better to document where the data came from, and leave any interpretations as to the trustworthyness of that source up to whoever is using the data.
Last updated: Apr 12 2022 at 19:14 UTC
