Stream: patient empowerment
Topic: Helping guide data collection
Lloyd McKenzie (Nov 17 2020 at 15:49):
In the discussion with Hanah (@Dave deBronkart - see if you can get her to sign up here so we can include her in conversations directly :>), I'm thinking that one 'technical' tool that could be helpful is a set of standardized questions that are organized and designed to be patient friendly and could be used to capture both subjective and objective data in a consistent way to a level of detail that the patient themselves find useful. So giving an ability to capture 'story', but also can use the 'story' bit to capture metrics both about a patient's "level of function" in every day life, possibly along multiple axis as well as drilling down to capture specific symptoms. Ideally an app could be tuned to present the metrics and symptoms most relevant to a particular condition as well as most relevant to a particular patient, based on past responses (while still allowing people to capture 'new' things that they notice and feel are important). The data elements would ideally be mapped to standardized clinical terminologies and FHIR resources to make it easy to take the results and expose them in a way that clinical and research systems can easily consume. Patients could choose whether to track their data for personal use, share with specific providers, grant anonymized access for research purposes, etc.
This wouldn't be an 'easy' project, but I think it's a completely doable project. Creating one-off, disease-specific solutions isn't very efficient and results in a lot of re-inventing the wheel. If we could come up with a generic solution with good mobile and web-based clients that the public could work to translate to different languages and cultures, the energy creating lots of little semi-functional solutions could instead support and enhance a general-purpose better scaling and more capable solution
Dave deBronkart (Nov 17 2020 at 23:03):
Lloyd McKenzie said:
In the discussion with Hanah (Dave deBronkart - see if you can get her to sign up here
You mean @Hannah Wei ?? My goodness, I do believe I got her in here last week. :-)
Seriously, I'm so glad this issue stimulated thought. Heaven knows neither she nor I has a clue what might be possible, beyond "Can't we do SOMETHING?"
Continued -
Dave deBronkart (Nov 17 2020 at 23:14):
one 'technical' tool that could be helpful is a set of standardized questions that are organized and designed to be patient friendly and could be used to capture both subjective and objective data in a consistent way to a level of detail that the patient themselves find useful.
That sounds like a nearly acrobatic achievement.
So giving an ability to capture 'story', but also can use the 'story' bit to capture metrics both about a patient's "level of function" in every day life, possibly along multiple axis as well as drilling down to capture specific symptoms.
Ditto / ibid.
Ideally an app could be tuned to present the metrics and symptoms
most relevant to a particular condition
as well as most relevant to a particular patient,
I'll ask others to comment on the feasibility of that! (As a former product manager I'm well capable of requesting features that make developers gag ... but then, is there a chance some sort of "empathetic A.I." tool might have access to configuration settings??? (Insane blue sky there)
based on past responses
(while still allowing people to capture 'new' things that they notice and feel are important).
Wow, you seriously got it. We're really talking about emergence, aren't we ... "all knowledge to date about this is tentative, and this is an emergency, so let's be methodical and proactive about seeking new observations." Are there precedents for how to do this in other sciences, or other ill-defined medical conditions?
Continued again - jeeze, you wrote ALL this in one paragraph :-)
Dave deBronkart (Nov 17 2020 at 23:21):
The data elements would ideally be mapped to standardized clinical terminologies and FHIR resources
"Ideally" indeed. Here we encounter the giant gulf between what they might want to express and what can currently be expressed in those terms. What do you do with things that don't fit? TBD I suppose.
This wouldn't be an 'easy' project, but I think it's a completely doable project.
Game on!
If we could come up with a generic solution with good mobile and web-based clients that the public could work to translate to different languages and cultures ...
Are you proposing we design a generic new-disease/new-experience symptom-capturing framework??
Thank you so much for this brain dump - no idea why I didn't see it this morning. I've pinged Hannah to get in here when she can.
Lloyd McKenzie (Nov 17 2020 at 23:22):
I know we have mechanisms to define standard structures containing data elements - including linkages to allowed answers, ability to define hierarchy, standardized question text, separately maintained files that provide translations. We can also define questionnaires that reference those data elements and support automatic extraction into other FHIR resources. And we can maintain both of those things in Git, allowing contributors to propose changes, create forks, allow community review, etc. We also have open source apps that know how to render those questionnaires and guide people through capturing answers. So I think the building blocks are in place. Trickiest bit I think would actually be the repository for patient data. Who would be trustworthy as a custodian, particularly on an international basis?
Lloyd McKenzie (Nov 17 2020 at 23:23):
I'm not super worried about expression. Much of it will be observations. It's possible we might occasionally identify things that don't have a LOINC code, but we can define a temporary code for those things and HL7 has a decent progress for requesting new LOINC codes when needed.
Dave deBronkart (Nov 17 2020 at 23:27):
Lloyd McKenzie said:
It's possible we might occasionally identify things that don't have a LOINC code, but we can define a temporary code for those things and HL7 has a decent progress for requesting new LOINC codes when needed.
I keep wondering if "COVID toes" exists in any vocabulary.
The other thing is that since this virus was only first documented a year ago this month, there's a chance we'll continue to discover new things too.
Lloyd McKenzie (Nov 17 2020 at 23:30):
Absolutely - but we can define custom codes for those quickly and then define mappings to standard codes once those are available.
Dave deBronkart (Nov 17 2020 at 23:33):
Lloyd McKenzie said:
Absolutely - but we can define custom codes for those quickly and then define mappings to standard codes once those are available.
I'm guessing "those" refers to things like COVID toes and other symptoms yet to come.
I imagine @Hannah Wei and her community will want to thoroughly understand what you're saying FHIR offers. Should we start by trying to do that with the entire list of symptoms they're looking at now? (At least the ones that have a name by now.)
Lloyd McKenzie (Nov 17 2020 at 23:39):
Seems reasonable. I don't have the bandwidth to do the work, but happy to point volunteers to the right place and provide guidance.
Hamish MacDonald (Nov 18 2020 at 08:14):
I saw @Hannah Wei FHIR DevDays presentation yesterday, and your thread here @Dave deBronkart and @Lloyd McKenzie , and it just seems like the right time to share what we have been doing. We have actually been working on this problem for some time.
TLDR VERSION: WE HAVE BUILT A SURVER BUILDER APP THAT DOES A LOT OF WHAT DAVE AND LLOYD PUT DOWN IN THEIR WISH LIST ABOVE FOR HANNAH WEI AND COVID PATIENT RESEARCH. IT IS A POC, BUT IT WORKS PRETTY WELL. WE WANT TO MAKE IT BETTER. IF OF INTEREST, READ ON BELOW WHAT IT DOES, AND PLEASE JOIN US! WE WOULD LIKE TO OPEN UP DEVELOPMENT WITH THE COMMUNITY.
We have built a POC that works fine and does most of what you are describing, but we want to keep developing it to make it better for all researchers and all subjects. We call it simply “The Survey Builder” (TSB). It is fully FHIR and SNOMED CT compliant, so all data relationships captured can be easily compared / analyzed with other researchers (whether COVID or any other researchers). We used FHIR R4 with SDC and Snowstorm Terminology Server.
For a bit of fun last night we used TSB to replicate the first 21 questions of @hannah COVID-19 Patient Experience Survey #2 and it worked well. Because we “live” in it we see some current limitations but it provides a good base for what you are describing above.
Thanks to Dave’s introduction I have been in contact with Hannah and we look forward to showing her what her team’s COVID survey looks like on TSB, as it seems to hit many of her key requirements: The researcher can create survey sets of questions that have value sets and rules tuned to specific conditions or fact-finding surveys.
It is simple for patients to enter data and they can see their data because it is in their instance of the app, and it has the capacity for patient-friendly terms to be used as well as professional terms, and of course it has the underlying SNOMED CT codes, plus FHIR resources of course, so patients can easily communicate their symptoms and experiences to medical professionals AND machines.
Plus the structured data can flow both ways, so the patients (let’s call them “Data Owners” – after all it is their data), can get the data and also results back too. The app is designed specifically for back and forth Data Owner / Clinician / Researcher interaction.
And this may also be interesting; the data structure in the app is designed to build on what the Data Owner has previously entered. I am not sure exactly what format and type of data / reports Hannah wants to feed back to their patients, but the app is designed to be a two-way data share, so I imagine most things should be doable.
And since the data entered by the Data Owner is owned by them in their own instance of the app, the data can be explicitly permissioned by them to share as they see fit, wherever they wish it go. This can also significantly lessen Custodial Data worries that providers typically have about receiving patient data that the patient may not have explicitly given consent for a particular research use case or analysis.
Oh, and the TSB works on web or mobile.
Hamish MacDonald (Nov 18 2020 at 08:16):
We are happy to work in an open development manner with the FHIR community to extend this Survey Builder so the whole world can use it if there is interest and if it can provide a good base to build from.
Our goal has always been for this Survey Builder to be a public service that can serve the whole community of researchers and survey subjects, rather than a business in and of itself. Sometimes sharing can make the biggest impact.
Let me introduce @Roheeni Bhana and @Matthew Valentine , who built TSB. Both of you please come on in and say, “Hello, World!”.
Maybe this can be of utility right now at the working POC stage for Hannah and other researchers. After all, we know how much work and prior thought and experimentation it took to get to this point, and it seems to do (or else will soon) most of what Hannah is looking for and that Lloyd and Dave describe.
And to anyone out there in the community, we would love your ideas or help to improve it if you are interested.
Roheeni Bhana (Nov 18 2020 at 08:33):
@Hamish MacDonald thank you! Hi everyone. Happy to be part of this group and thread. Hamish has described what we have developed as a POC perfectly. With New Zealand adopting FHIR and SNOMED CT we felt it was vital that we developed a tool that was going to be flexible in gathering structured and compliant data and to ensure interoperability. @Ilya Beda our tech lead is more than happy to answer any technical questions anyone may have. @Alastair Kenworthy
Matthew Valentine (Nov 18 2020 at 08:36):
Thanks @Hamish MacDonald and credit belongs to @Roheeni Bhana for her going it alone for several years to make a FHIR and SNOMED app a reality. Like Roheeni said, flexibility is very important and @Ilya Beda and his team have really delviered.
Roheeni Bhana (Nov 18 2020 at 08:37):
It was a total team effort @Matthew Valentine and @Ilya Beda
Ilya Beda (Nov 18 2020 at 09:13):
Hi!
It is nice that we are finally public and can present what we did to the community.
TSB is built on top of open-source I developed during FHIR сonnectathons questionnaire tracks.
If you are interested in low-level aspects of TSB and how we utilize SDC please join my session on devdays.
I will present on Nov 19, 2020 - 8:00 AM CET
https://whova.com/portal/webapp/hfdn_202011/Agenda/1251982
Olivier Karasira (Nov 18 2020 at 19:12):
Roheeni Bhana said:
Hamish MacDonald thank you! Hi everyone. Happy to be part of this group and thread. Hamish has described what we have developed as a POC perfectly. With New Zealand adopting FHIR and SNOMED CT we felt it was vital that we developed a tool that was going to be flexible in gathering structured and compliant data and to ensure interoperability. Ilya Beda our tech lead is more than happy to answer any technical questions anyone may have.
@Matthew Valentine @Lloyd McKenzie @Dave deBronkart @Grahame Grieve @Leona ISHIMWE @Pamela IZERE @Joanna Usifo
Greeting from AFRICA !!! WITH OUR SURVEY BUILDER
Today we are introducing the first and only end-to-end SNOMED and FHIR compliant forms.
This video is a glimpse of what we are using to build surveys for clinicians and Data Owners at The Sovereignty Network and Cure8health.
Hamish MacDonald (Nov 18 2020 at 19:40):
Nice explainer video @olivierkarasira @Pamela IZERE @Leona ISHIMWE @Joanna Usifo especially as I woke up this morning to find you all put this together literally in a few hours. Hopefully this helps folk on this thread understand what Roheeni and I wrote about above. A picture speaks a thousand words, right?
Dave deBronkart (Nov 18 2020 at 22:12):
It looks nice (though the music is a bit loud), but being non-technical I'm still not at all clear about what this means to someone like @Hannah Wei . Hannah, are you?
For me what would be helpful is an example of what would normally come out of a survey (e.g. SurveyMonkey) - is it a plain CSV? And then how the same responses come out of this survey builder.
I imagine the answer is that CSV contents are grossly unusable for import into an EMR or app, is that right? But when the same info comes out of TSB, it's ready to import? Am I oversimplifying? If I have the idea right, it would be superb to show the responses popping up on an EMR screen.
Hamish MacDonald (Nov 18 2020 at 23:17):
@Dave deBronkart Could plain CSV data be imported and combined with TSB survey data? Sure. But why use CSV data at all when you can simply re-create the survey questions in the TSB and now have every piece of data within the survey be computable medical knowledge using SNOMED and FHIR.
That's basically what we did when we recreated Hannah's first 21 questions in the COVID Survey into the TSB. (Don't worry, we aren't using it @Hannah Wei we were just playing around to prove it can be done :grinning:)
AND all under the control of the patient (Data Owner) = Patient Empowerment. The Data Owner wouldn't even know it is SNOMED and FHIR under the covers - they are just answering questions or adding information in their native language on the screen.
They can then share it not only back to the researcher, but now the data also sits in their personal interoperable health record in the app they use, so any of the data points they entered in the COVID survey can also be shared elsewhere as highly structured data (it is not just "info" anymore) and can go to any FHIR 4 compliant system, including "popping up in an EHR". as you suggest.
From there, a whole lot of data relationships could be examined using SNOMED CT either for an individual or across a cohort or even a population.
If you want to get fancy, at that point real time analytics, pop health, follow ups, alerts, automatically generated next steps, educational delivery, triage etc. all begin to become possible.
Dave deBronkart (Nov 23 2020 at 17:36):
News: on Sunday the well-renowned Parkinson's e-patient Sara Riggare tweeted that she's tested positive for the virus. She's also a PhD candidate at Karolinska Institute, pursuing a doctorate in self-study. (Imagine that.)
So it's no surprise that she just blogged about self-tracking her COVID-19 symptoms, including creating a Google Form to model the symptoms recommended in this recent BMJ Open article:
“What items should be included in an early warning score for remote assessment of suspected COVID-19? Qualitative and Delphi study”: https://bmjopen.bmj.com/content/10/11/e042626.
Please, all interested in this subject, take a few minutes to read her post. How often do we have a PhD candidate researcher drop into a topic due to intense personal interest?
cc @Lloyd McKenzie @Grahame Grieve
Dave deBronkart (Nov 23 2020 at 20:35):
There's so much to this subject! On Twitter today our keynoter @Hannah Wei responded to the Sara Riggare story by pointing to a thread about challenges in data collection. Recall that Hannah's one of the leaders of the patient-led research project. As the thread suggests, one of the challenges they encountered was that comprehensive symptom logging can wear people out,, which is not a good fit for this disease.
Why did you stop? This may underestimate Longcovid https://twitter.com/Caitrionakelly4/status/1309460841167835136
- Tim Spector (@timspector) Ryan Howells (Dec 01 2020 at 01:33):
@Hamish MacDonald @Roheeni Bhana @Ilya Beda Where is the technical documentation available for what you built?
Ilya Beda (Dec 01 2020 at 04:30):
Hi @Ryan Howells
You can start with this video from FHIR meetup® https://youtu.be/l7yjHVo7t7I?t=2168
I describe system technical details on the high-level there.
Also, there is one more video from DevDay but it is not public yet.
I am just wondering what kind of technical documentation you are interested in?
Last updated: Apr 12 2022 at 19:14 UTC
