Stream: patient empowerment
Topic: How would pt defined symptoms work?
Dave deBronkart (Nov 30 2020 at 16:57):
It's stimulating to know that work is afoot on capturing patient contributed data (the project in our WG, and more) but perplexing to ponder the needs of patients whose symptoms may not fit into any existing lexicon. How does one do that?
Example: how would something like "brain fog" get handled in FHIR?
At DevDays we heard from 15 min video the LongCOVID community, particularly re the patient-led research team. Capturing their symptoms as experienced by them is essential to them; shoehorning reports into someone else's taxonomy is not useful.
Fascinating short thread:
What dx code should be used for brain fog?
- maybe 348.8 or 348.9...
- I'd go with "other" symptoms - something with a code - was the patient dizzy? light headed? forgetful? headache? tingling?
something - some other symptom
John Moehrke (Nov 30 2020 at 18:53):
For a patient to report? Likely this would be reported just using human narrative. And this is why all codes can be recorded just as free-text. Trying to nail down to a code something this nebulous is more likely to cause trouble than help. For example the patient might choose ICD-10-PCS S06.2X0 (https://www.icd10data.com/ICD10CM/Codes/S00-T88/S00-S09/S06/S06.2-/S06.2X0) which might be right, but sure does imply some professional decision about a bunch of alternatives.
Dave deBronkart (Nov 30 2020 at 19:31):
Thanks, @John Moehrke . So I'm wondering - and I know this is vague: is there any way at all to use FHIR or anything else to collect and aggregate info about recurring themes in patient narratives, during the phase of a new condition where we don't yet know what "things" are worth turning into named "things"?
John Moehrke (Nov 30 2020 at 19:35):
data mining??? Not very privacy friendly.... This is indeed the kind of "normal operations" that healthcare providers do under the conditions of HIPAA Treatment, Payment, and "Normal Operations". A PHR product might include these kinds of carve-outs in their terms-and-conditions. But would it be possible for this to be done on the scale of HL7 organization? No way.
John Moehrke (Nov 30 2020 at 19:40):
one does tend to find that a vocabulary (e.g. LOINC, SNOMED, ICD, etc) do tend to know the common language terms that something specific is also-known-as. Where for any phrase there is likely a wide number of possibilities. Thus, given this, one could in their User-Interface suggest the alternatives in a pick-list. (I am doing this with a patient entered medication, lookup alternatives in RxNorm, and have the patient pick the best). The drawback is that the patient is just as likely to think the best is the right one, as to pick the best and have it be totally wrong. There is benefit to being vague, vs looking like you picked a specific value with intent.
John Moehrke (Nov 30 2020 at 19:40):
this would be one use-case for CDS-Hooks (not the only one, and likely not a really good one)
Dave deBronkart (Nov 30 2020 at 19:43):
John Moehrke said:
data mining??? Not very privacy friendly.... This is indeed the kind of "normal operations" that healthcare providers do under the conditions of HIPAA Treatment, Payment, and "Normal Operations". A PHR product might include these kinds of carve-outs in their terms-and-conditions. But would it be possible for this to be done on the scale of HL7 organization? No way.
Ah, fascinating! I was in fact not thinking at ALL of any "data mining" being done by providers. I was talking about some totally democratized workflow, not necessarily involving any traditional providers. Perhaps it could be among the BodyPolitic patient-led researchers ( @Hannah Wei 's keynote) to share data amongst themselves, in a format that can then easily be shared IF THEY WISH with other researchers globally, the CDC, whatever.
Dave deBronkart (Nov 30 2020 at 19:46):
In that regard, it's not unlike what @Olivier Karasira and @Hamish MacDonald etc are doing, in creating data that's "born free" outside of any heath system.
Dave deBronkart (Nov 30 2020 at 19:51):
John Moehrke said:
one does tend to find that a vocabulary (e.g. LOINC, SNOMED, ICD, etc) do tend to know the common language terms that something specific is also-known-as. Where for any phrase there is likely a wide number of possibilities. Thus, given this, one could in their User-Interface suggest the alternatives in a pick-list. (I am doing this with a patient entered medication, lookup alternatives in RxNorm, and have the patient pick the best). The drawback is that the patient is just as likely to think the best is the right one, as to pick the best and have it be totally wrong. There is benefit to being vague, vs looking like you picked a specific value with intent.
Thanks for helping with my / our wandering on this, John. I'll step back out of the weeds and "genericize" my question to this example:
Let's say I have an odd symptom or syndrome that medical science has never seen, but I have absolutely established that it correlates with (or foretells) something else - diarrhea, premature ventricular contraction, leg cramps. Is there anything in FHIR that would let me capture the occurrence of that symptom? If I were as savvy as @Keith Boone or you, could I create my own FHIR extension?
I find myself imagining a WITHIT resource: What In The Heck Is This.
John Moehrke (Nov 30 2020 at 19:55):
Okay, very different mechanics to the same goal... I think... for your mechanics... I think a use of Condition would fit. http://build.fhir.org/condition.html
It would allow for the masses to submit how they perceive their conditions. The details can be vague or get linked tighter and tighter. The engine could then look for similarities, group them (affinitize). etc.
What you describe would require that submissions would need to be carefully watched to assure the data was always authentic (not scams), while not identifying (likely using a de-coupled pseudonymization mechanic).
John Moehrke (Nov 30 2020 at 20:01):
this is not unlike what happens at google based solely on google search terms... it is why they are so good at what they do
Lloyd McKenzie (Nov 30 2020 at 20:31):
You might choose to limit the data capture (on submission) to free-text perhaps with very high-level categorization codes to prevent misclassification by parents/care-givers who don't necessarily have a good grasp of the terminologies. (Yes, some patients can probably code things better than the clinicians themselves, but those would be the minority.)
Dave deBronkart (Dec 01 2020 at 04:23):
Thanks to both of you, @Lloyd McKenzie and @John Moehrke ... I'm starting to feel like I might get a grip on some part of FHIR reality. Time will tell.
Really seems apt, though there's no chance I could have picked it out -
Condition is one of the event resources in the FHIR workflow specification.
This resource is used to record detailed information about a condition, problem, diagnosis, or other event, situation, issue, or clinical concept that has risen to a level of concern. The condition could be a point in time diagnosis in context of an encounter, it could be an item on the practitioner’s Problem List, or it could be a concern that doesn’t exist on the practitioner’s Problem List. ...
Dave deBronkart (Dec 01 2020 at 04:27):
@Hannah Wei I'll tag you here in case you want to come find this later. LMK if the point isn't clear. Good comments especially from Lloyd and John.
Last updated: Apr 12 2022 at 19:14 UTC
