Stream: patient empowerment
Topic: USCDI <=> FHIR reality check pls?
Dave deBronkart (Sep 22 2020 at 02:24):
Hey USCDI gurus: a question arose in email: This "brings up the question of the continuing relevance of USCDI at all, since by the time any updates would be implemented “all EHI” would have to be provided by regulation. Did the group discuss this aspect?"
Someone replied
The “all EHI” in the mandate does not require the covered entity to provide the data in FHIR format. I believe USCDI is specific to FHIR format. So, identifying the most important elements we would like to be shared via FHIR is important and relevant.
Reality check on all the above, anyone?
Josh Mandel (Sep 22 2020 at 02:26):
Yes, that reply is basically right. ONC has a path forward for standardized data (USCDI) and a path for all data whether standardized or not (EHI Export). The idea is that over time, USCDI chips away at the size of the "dark" (non-standardized) data -- though in practice health science keeps growing, so I doubt the gap will net shrink.
Josh Mandel (Sep 22 2020 at 02:28):
My personal take is that non-standardized data will be with us forever (we'll never standardize everything; the frontier keeps moving) and will be super damn useful, so I'm dismayed that ONC's EHI Export requirements include no concept of automation.
Josh Mandel (Sep 22 2020 at 02:30):
https://smarthealthit.org/2019/05/final-smart-team-comments-on-the-21st-century-cures-act-interoperability-rule/ has a section called "Provide API Access for Data Exports" that captures my perspective, and some background.
Dave deBronkart (Sep 22 2020 at 02:54):
Thanks Josh!
Virginia Lorenzi (Sep 22 2020 at 03:29):
@Josh Mandel under HIPAA data can be shared for TPO without a patient moving it. When you sign the HIPAA form you "know" that. The way covered was used just meant covered entity provides an API (through which one could request data). Also, while it is clear that all data, standardized, is desired, that is not what ONC is asking for sadly.
Brendan Keeler (Sep 22 2020 at 04:24):
Josh said it best.
Simply best, the EHI rule is so vague that it'll just come down to how EHRs implement it.
USCDI's benefit is its uniformity. So it's relevant and powerful, assuming we get that ubiquitous uniformity.
Vassil Peytchev (Sep 22 2020 at 04:28):
I disagree with Josh on the usefulness of non-standard data. Mainly because there will be no agreed upon context for the data, and without an understandable context the data will not be useful.
We've seen that when claims data was attempted to be used for personal health information it didn't work. I think even @Dave deBronkart had similar experience, and I believe that it is that lack understood context that will severely limit the usefulness of non-standard data.
USCDI, on the other hand, can help provide a sustained expansion of standardized data sharing with the appropriate support of the US Core IG. I just hope that the effort expended for the required implementation of EHI export doesn't get in the way of the continued development of USCDI.
Virginia Lorenzi (Sep 22 2020 at 07:34):
@Brendan Keeler We are working on submitting proposals for USCDI - You had some good ideas - would you be able to take a stab at the form? Also, we wanted to try to be a bit more generic and use your ideas as examples. Like a new class of Structured Clinical Observations with the different datasets as examples. Not sure if it would fly. Examples of filled out forms here https://confluence.hl7.org/rest/hotovo/amazon-s3/1.0/buckets/33/content/download?path=USCDI%20Proposals/TREED%20USCDI-ONDEC-Submission-Form-Prep-Sheetv2%20(1).docx&targetId=86974077 and here: https://confluence.hl7.org/rest/hotovo/amazon-s3/1.0/buckets/33/content/download?path=USCDI%20Proposals/USCDI-ONDEC-Submission-Form-Prep-Sheet-consents.docx&targetId=86974077
Dave deBronkart (Sep 22 2020 at 11:22):
Vassil Peytchev said:
We've seen that when claims data was attempted to be used for personal health information it didn't work. I think even Dave deBronkart had similar experience, and I believe that it is that lack understood context that will severely limit the usefulness of non-standard data.
Yes, @Vassil Peytchev, your link is about my case. :smile: It was what involuntarily launched me on this crusade 11 years ago, and was a core part of my ten part series last year on why FHIR is essential: An information quality trainwreck: Google Health revealed the mess in my hospital’s data
BUT - and importantly - this very much does not mean there should be any limits on what data can be moved around, because creating those limits means we have decided a priori that there couldn't possibly be any value to that data being moved around. We (all) are in no position to know what in that "big fat file folder" might be needed and why.
It DOES mean, though, that while we should allow it all to get moved around, we shouldn't at all assume that it's valid. History has taught us that it can contain lots of garbage as well as gold (and tin etc).
In short, the usefulness for automation is severely limited by the unknown content of that blob of stuff - but to me that simply means that a blob is a blob and its processing cannot be automated. But blobs cannot be disallowed.
This may be worthy of further discussion & documentation by this WG, if people feel that way.
Josh Mandel (Sep 22 2020 at 12:40):
I disagree with Josh on the usefulness of non-standard data. Mainly because there will be no agreed upon context for the data, and without an understandable context the data will not be useful. We've seen that when claims data was attempted to be used for personal health information it didn't work.
I believe Dave's case was actually an example of creating a standardized data payload (CCR? CCD?) with the wrong data (clinical fields incorrectly populated with information from claims). Data quality is a persistent problem no matter how you write things down -- but the more pressure there is to write things down in a "standard" way, the easier it becomes for Dave's story to repeat itself (because sometimes when you are focused on strictly following a standard, you lose the ability to convey nuance and context).
Don't get me wrong, I love standards, but it's unfair to say that non-standardized data (particularly) will lead to these kinds of misinterpretation issues.
Brendan Keeler (Sep 22 2020 at 13:54):
I took a look at the form a few weeks ago and found the process a bit complex. I can take another look with the examples you put together.
Dave deBronkart (Sep 22 2020 at 17:47):
Josh Mandel said:
I believe Dave's case was actually an example of creating a standardized data payload (CCR? CCD?) with the wrong data (clinical fields incorrectly populated with information from claims).
For what it's worth, here's Halamka's May 2008 declaration of victory saying that they'd finalized their Google Health interface. It cites "a proprietary form of CCR, CCR/G" (for Google) and CCD, but I have no clue what reality was. I'd welcome any insights from anyone who was involved back then.
Just for posterity, here are my blog posts from that 2009 episode.
- 3/01/09: I’m putting my data in Google and HealthVault - my post expressing interest in seeding an ecosystem of health apps
- 4/01/09: Imagine someone had been managing your data, and then you looked. - the post that described what happened when I clicked the button
- 4/09/09: The I in IT stands for Information - an attempt to explain (as an ordinary data jockey) what IT is about. (Jeeze, was it really necessary to explain this?? Yes, too many people in health IT were acting as if this was all a surprise.)
- 4/12/09: Encoding information is part of IT - ditto
- 4/17/09: Quick update on moving my data - the outcome of the call we had with Halamka, which ended with the decision to stop using billing codes as a proxy for reality (arg)
- 4/18/09: Globe follow-up on my hospital’s decision to stop transmitting billing data as clinical history
- 4/19/09: Completing my list of billing code errors - a rather bone-chilling list of insanities
Virginia Lorenzi (Sep 23 2020 at 06:31):
It is an unweildy form but I was able to throw one together with some stuff blank for advanced directives
Maria D Moen (Sep 24 2020 at 14:11):
I'd like to see us work on USCDI next week as a focused group, rather than with attendees who need to be enticed to stay with us and grow as we grow. Can we backlog the USCDI discussion to next week?
Dave deBronkart (Sep 24 2020 at 14:42):
@Maria D Moen are you saying DON'T discuss this week, or continue next week?
Maria D Moen (Sep 24 2020 at 14:53):
I'm saying I'd like to dig into the USCDI topic next week, not this week. We're spread pretty thin this week and I find value in working on items that draw people to our group instead of digging into more detailed, painstaking work.
Dave deBronkart (Sep 24 2020 at 14:58):
@Virginia Lorenzi I too am feeling like we have more than enough with our IG and WP projects; we're already bumping Pt Contributed Data out of the current session.
Co-chairs @Debi Willis and @Abigail Watson what are your thoughts?
Abbie Watson (Sep 24 2020 at 15:18):
USCDI next week is fine with me.
Virginia Lorenzi (Sep 24 2020 at 15:46):
I agree about drawing people in. I really just want to get suggestions for USCDI to PAC since they will be making final decisions anyway. They are on a short timeline to pull it all together and we may run out of time.
Dave deBronkart (Sep 24 2020 at 15:50):
what is their short timeline? I wonder if we can collect the suggestions you seek in some format besides meeting time
Last updated: Apr 12 2022 at 19:14 UTC
