Stream: patient empowerment
Topic: Vote for your Favorite: Patient Corrections Architecture
Virginia Lorenzi (Feb 24 2021 at 05:44):
Please make sure to open this document and vote for your number 1 and number 2 choice by 8PM eastern tomorrow.
https://docs.google.com/document/d/1Q_Vln_Vb21JVu1rPgwPZ68_IyTlktuuSGGJLm9kGSY4/edit?pli=1#
We will be discussing it at the Patient Request for Corrections call at 10AM Eastern this Thursday:
Patient Corrections Weekly Call
Join Zoom Meeting https://hl7-org.zoom.us/j/93069166841?pwd=NnpNclVWNFhzNGhEYXVFMW84eWlHUT09 Meeting ID: 930 6916 6841 Passcode: 997467 One tap mobile +16465588656,,93069166841# US (New York) +13126266799,,93069166841# US (Chicago)
10:00 AM - 11:00 AM
@Vassil Peytchev @Lloyd McKenzie @Josh Mandel @Cooper Thompson @Jeffrey Danford @Drew Torres
Lloyd McKenzie (Feb 24 2021 at 14:31):
I'm not voting because in the end, it's the opinions of implementers that matter. I know what I'd like to see happen in terms of functionality, but implementers know what their capacity is. What I do care about is that whatever approach we use in terms represents an appropriate use of FHIR. I.e. we can't use resources in ways that are contrary to their semantics.
Josh Mandel (Feb 24 2021 at 16:09):
I also am not voting; I don't think this kind of design decision works well by committee.
Virginia Lorenzi (Feb 26 2021 at 07:06):
we are just using the voting to narrow the choices and help steer the discussion. Agree that we want implementers to think about it. I think we had more useful discussion today.
Dave deBronkart (Feb 26 2021 at 19:37):
HEY ALL Y'ALL! I haven't been in on ALL the nerd wars :-) about these legitimate debates, but PLEASE PLEASE, speak up! Everyone agrees that this is going to be important (per the Expert Panel we had at the Connectathon) - engage please
John Moehrke (Feb 26 2021 at 19:42):
I think the voting is best done by implementers putting into code what they think you are asking them to do, and then discussing the issues they were presented with. Followed by the committee listening to that feedback and adjusting, possibly pivioting. Consensus building is a long drawn out process that hardly ever ends up on the first solution presented. Votes tend to go to the noisy (or money)
Lloyd McKenzie (Feb 26 2021 at 19:54):
What matters here is what implementers are willing (and able) to do with a timeframe of 1-3 years. The opinions/preferences of other participants matter somewhat, but implementers hold the trump cards.
Dave deBronkart (Feb 27 2021 at 16:44):
Lloyd McKenzie said:
What matters here is what implementers are willing (and able) to do with a timeframe of 1-3 years. The opinions/preferences of other participants matter somewhat, but implementers hold the trump cards.
@John Moehrke and @Lloyd McKenzie I totally agree! I keep telling people, the distinctive thing about HL7 seems to be its emphasis on standards that are actually worth doing and feasible.
My trumpet was based solely on parroting what co-chair @Virginia Lorenzi said ("Vote!"), which was not narrowed with "Hey implementers!" :-)
Virginia Lorenzi (Mar 03 2021 at 04:52):
Would rather not go to the connectathon and try 30 different resources. We already put a decent amount of work into profiling Task. Its OK to start over. But where? So we are just trying to narrow things to a couple options and especially get people's perspectives on what is doable and orthodox. The Vote is not a ballot clearly its just at this point in time what are you most leaning towards. We would like to test as early as April and want to prepare for that. At the WGM, we created a list of all the specifying we need to do once we pass this logjam so would like to find a way forward so we can get to those other work items. Implementers on the server side that actually manage the request for correction workflow are voices we are especially interested in but we do want all. We also want the opinions of those that really understand FHIR nuances.
Virginia Lorenzi (Mar 03 2021 at 04:56):
@Hans Buitendijk @Jenni Syed @Drew Torres Cerner guys we would really like your opinion on direction for patient request for corrections. Please see the options here: https://docs.google.com/document/d/1Q_Vln_Vb21JVu1rPgwPZ68_IyTlktuuSGGJLm9kGSY4/edit?pli=1
or if you think we are missing something let us know.
Josh Lamb (Mar 11 2021 at 19:51):
I added a line to the google document. Will it be taken offline when "voting" is closed? Thanks for putting this together @Virginia Lorenzi .
Abbie Watson (Mar 14 2021 at 05:02):
Lloyd McKenzie said:
What matters here is what implementers are willing (and able) to do with a timeframe of 1-3 years. The opinions/preferences of other participants matter somewhat, but implementers hold the trump cards.
I disagree rather strongly with that timeframe. The assumption of 1-3 years assumes institutional stakeholders that are well resourced and can think in terms of multi-year rollouts. Patient implementors and the startup community they inhabit, on the other hand, have much shorter runways where they need to be able to prove a prototype, or otherwise their projects will starve, crash, and burn. Assuming a 1-3 year implementation timeframe might be fine in other areas of HL7, but I think it's egregious to apply that same yard stick to Patient Empowerment activities. If a Patient Implementor or startup can't implement an IG within 3 months, the IG is effectively worthless. IG users should NOT have to wait 'a few years down the road' for an IG to be useful.
Personally, I'd like to see a motion for the PE Workgroup to constrain itself to only writing IGs that use resources that are Maturity Level 4 or 5 - meaning that Patient Implementors and other stakeholders who implement the IG can anticipate a higher level of adoption of the spec when they pick the IG up. That would cut the timeframe to less than a year. FHIR-I might have the luxury of considering 1-3 year timeframes, but patients and startups generally don't have that luxury.
(I realize that such a motion wouldn't get a majority, but it would get my vote.)
Lloyd McKenzie (Mar 14 2021 at 06:53):
I'm not saying the IG can't be done within 3 months, and a start-up could easily do the same. But I think 1-3 years is realistic (maybe even optimistic) for a timeframe of EHR vendors turning the IG into reality, getting it out into the field and have hospitals and clinics turn it on.
The maturity level has little bearing on what the EHR vendors can/can't do. They rolled out lots of level 2 resources in DSTU2 and rolled out quite a few more in R4. The timeframe isn't driven by the maturity of the resource, it's driven by the difficulty (and prioritization) of integrating the interoperability functionality into whatever layer of their system needs it. The choice of resource will be driven by "what works best for the functionality they want to expose - and what the standard says the resource is for". (EHR vendors have been remarkably good about trying to align with the documented purposes of the resources they use, even as those definitions evolve.)
The layer we're talking about in terms of patient corrections isn't a layer that has any interoperability right now (as I understand it), and the priority level of this effort isn't going to be as high as the numerous interfaces that have short-term regulation behind them. So, we need to listen carefully to what the EHR vendors are willing to do. Because if the Patient implementers and other stakeholders don't have systems they can actually talk to and drive corrections, we haven't got much. It took roughly two years from time of commitment to when DSTU2 systems were live and it's been taking roughly the same for R4 interfaces. I see no reason why patient corrections would be faster (and some unfortunate reasons why it might be slower).
I agree that faster would be better and if the EHRs say they can have it turned on in hospitals in 6 months, I sure won't complain. I would, however, be exceptionally surprised. (And that goes for any interface using any resource at all.)
Last updated: Apr 12 2022 at 19:14 UTC
