Stream: social
Topic: Patient Empowerment
Grahame Grieve (Oct 10 2018 at 18:05):
I posted @Michael Morris's story on my blog today: http://www.healthintersections.com.au/?p=2879
Grahame Grieve (Oct 10 2018 at 18:05):
highly recommended reading for everyone
Grahame Grieve (Oct 10 2018 at 18:06):
I'd love to post other similar patient empowerment stories. or clinician empowerment stories as well
Grahame Grieve (Oct 10 2018 at 18:06):
Does anyone else think we should have a patient empowerment team/WG at HL7?
Michele Mottini (Oct 10 2018 at 21:30):
...we have a patient app that creates a combined medical record from multiple sources...but 'With FHIR, we can now integrate multiple vendor systems (e.g., EPIC, Cerner, AllScripts, etc.) on behalf of the patient via consent to create an integrated health record.' does not really work that well so far...basically only Epic is seamless (but without refresh tokens)
Michele Mottini (Oct 10 2018 at 21:31):
Cerner, Allscripts, eClinicalWorks, AthenaHealth, GE, NextGen, Meditech - blocked by problems of various kind
Grahame Grieve (Oct 10 2018 at 21:44):
what are the problems?
Michele Mottini (Oct 10 2018 at 22:04):
Cerner: apps have to be white-listed by each provider - and there is no easy way to contact them
Michele Mottini (Oct 10 2018 at 22:04):
Allscripts: same + providers are not even known
Michele Mottini (Oct 10 2018 at 22:05):
eClinicalWorks: invalid capability statement - reported back in June, never fixed
Michele Mottini (Oct 10 2018 at 22:05):
AthenaHealth: no SMART / OAuth - so no way for patients to authoriza na app
Michele Mottini (Oct 10 2018 at 22:05):
(although it appears that they did implement it for Apple - but not for other apps)
Michele Mottini (Oct 10 2018 at 22:06):
NextGen: their FHIR support is not really FHIR
Michele Mottini (Oct 10 2018 at 22:06):
Meditech: no SMART / OAuth
Michele Mottini (Oct 10 2018 at 22:07):
GE: custom authentication protocol
Michele Mottini (Oct 10 2018 at 22:08):
(I went through all vendors that are certified in the US for API access - the one above are those I made more progress with)
Michele Mottini (Oct 10 2018 at 22:09):
(Most of the other ones have custom APIs - no FHIR at all)
Grahame Grieve (Oct 10 2018 at 22:09):
NextGen: their FHIR support is not really FHIR
What does that mean?
Grahame Grieve (Oct 10 2018 at 22:09):
@Wes Rishel FYI
Michele Mottini (Oct 10 2018 at 22:10):
Their documentation states that they support FHIR but the REST calls are not FHIR
Michele Mottini (Oct 10 2018 at 22:10):
(they payloads might be but I did not get that far)
Grahame Grieve (Oct 10 2018 at 22:12):
ah yes. ok that makes sense.
Grahame Grieve (Oct 10 2018 at 22:12):
mainly, this is what you get when you mandate some API, and only encourage FHIR.
Grahame Grieve (Oct 10 2018 at 22:12):
Cerner: apps have to be white-listed by each provider
this is true for patient facing apps?
Michele Mottini (Oct 10 2018 at 22:13):
Yes
Michele Mottini (Oct 10 2018 at 22:15):
NextGen: GET https://fhir.nextgen.com/mu3api/dstu2/v1.0/assessment - Returns an array of patient assessments
Grahame Grieve (Oct 10 2018 at 22:15):
thx- this is good information.
Michele Mottini (Oct 10 2018 at 22:17):
You're very welcome...
Michele Mottini (Oct 10 2018 at 22:17):
(Details of all the certified systems here: https://docs.google.com/spreadsheets/d/1C9faN7Ne0DIgrmXbMVBcff9KTotuejIEbpr4ZPE3tUE/edit?usp=sharing )
Abbie Watson (Oct 11 2018 at 19:19):
We’re working across these issues also. Thank you @Michele Mottini for the synopsis; this is our experience as well. We would be happy to participate in a Patient Empowerment Team / WG.
Michele Mottini (Oct 11 2018 at 19:26):
No problem
Michele Mottini (Oct 11 2018 at 19:27):
more the EHR-Vendor-Nagging-Team ....
Grahame Grieve (Oct 11 2018 at 19:28):
I would be disappointed if that's all it was.
Michele Mottini (Oct 11 2018 at 19:28):
what do you mean?
Lloyd McKenzie (Oct 11 2018 at 19:30):
Access to data is just a first step to patient empowerment. (Though a very necessary and foundational step.)
Michele Mottini (Oct 11 2018 at 19:32):
ah yes ... we are trying to put useful thing for a patient in our app, but being stuck at getting data they are difficult to even test
Grahame Grieve (Oct 11 2018 at 19:34):
right. but beyond that... what is needed to empower patients? if the answer is simply access, and policy to make access happen, then HL7 is not the place. The question is, what technical standards are needed to help the policy process, and then, what else is needed beyond that
Michele Mottini (Oct 11 2018 at 19:35):
got it
Michele Mottini (Oct 11 2018 at 19:36):
from our prospective standard-wise FHIR DSTU2 + Argonaut + SMART is all that's needed
Michele Mottini (Oct 11 2018 at 19:36):
so nothing new to develop
Grahame Grieve (Oct 11 2018 at 19:37):
so your use case is pretty narrow. But even then: I think we need a few more standards to build that eco-system out. In particular: dynamic application registration, and an app endorsement specification. else app developers will not be able to scale
Michele Mottini (Oct 11 2018 at 19:39):
I disagree - adding those things will just make things more confusing and hinder adoption
Lloyd McKenzie (Oct 11 2018 at 19:39):
Patient empowerment often means access to your childrens' data or those of other dependents. So consent comes into play too
Michele Mottini (Oct 11 2018 at 19:40):
this is already handled internally to the EHRs
Grahame Grieve (Oct 11 2018 at 19:40):
adding those things will just make things more confusing and hinder adoption
really? so you think the current arrangement where you have to go negotiate with each provider to get patient access is workable?
Grahame Grieve (Oct 11 2018 at 19:41):
Cerner: apps have to be white-listed by each provider
Grahame Grieve (Oct 11 2018 at 19:41):
Epic is seamless (but without refresh tokens)
Michele Mottini (Oct 11 2018 at 19:41):
the apps are already centrally registered with Cerner - so adding dynamic registration would not change that
Jeffrey Danford (Oct 11 2018 at 19:42):
How are you defining whitelisting? We don't consider what we do fits that term.
Michele Mottini (Oct 11 2018 at 19:43):
what I understood is that the app that is registered with Allscripts developer portal would not be able to connect to providers end point
Michele Mottini (Oct 11 2018 at 19:43):
the provider has to enable it
Michele Mottini (Oct 11 2018 at 19:44):
but maybe I misunderstood?
Michele Mottini (Oct 11 2018 at 19:44):
(that's how Cerner works)
Jeffrey Danford (Oct 11 2018 at 19:45):
The patient has to be invited by the provider. Not the app. The registration is just to create the clientid, which gets pushed out automatically to the auth service.
Keith Boone (Oct 11 2018 at 19:46):
We support BOTH SMART, and a custom authentication protocol. Contact me (keith.boone@ge.com) for more details.
Michele Mottini (Oct 11 2018 at 19:47):
(Switching to direct messages for Allscripts and GE)
Michele Mottini (Oct 11 2018 at 20:30):
So correction:
Michele Mottini (Oct 11 2018 at 20:31):
Allscripts: apps are automatically enabled, but providers end points are not known
Michele Mottini (Oct 11 2018 at 20:33):
Concerning registration: Cerner, Epic, Allscripts, eClinicalWorks register the app centrally, and the resulting client ID is good for all the providers using their system - so app developers don't have to register their apps a million times
Michele Mottini (Oct 11 2018 at 20:34):
The difference is that for Epic the apps are enabled by default across all providers - and individual providers can black-list (disable) specific apps
Michele Mottini (Oct 11 2018 at 20:34):
With Cerner the apps are by default disabled, and the individual providers have to enable them
Michele Mottini (Oct 11 2018 at 20:35):
i.e. when you try to authenticate with one of those provider you get back an 'access denied' error = yes I recognize your client id, but I don't want your app to connect to my system
Michele Mottini (Oct 11 2018 at 20:36):
And changing this is not a technical problem, is the relationship between Cerner and their customers
Cooper Thompson (Oct 11 2018 at 20:49):
One thing that the broader patient empowerment community could help with is with creating an organization (or small set of organizations) that can review/vet/certify applications. If there were a certifying body that both EHR vendors and healthcare organizations could trust, that could do a lot help seamless application integration. @Michele Mottini - it seems like you are looking at this from an application developer perspective, which is very reasonable, but healthcare organizations and EHR vendors also need to consider the operational and data security implications. When apps don't work, inevitably patients will end up calling the helplines at healthcare organizations (who can't realistically be on the hook to support hundreds of apps they don't have any knowledge of). What is the end user support model that those organizations should adopt? Health care orgs are also rightly concerned that bad actors may create malicious apps and "phish" health data from patients - how can we prevent or mitigate those? And what happens when well-intentioned apps give bad advice that could harm patients? These sorts of questions I think are some of the major issues that need to be addressed before broadly adopted, "seamless" patient-centered data access can really flourish. These issues I think are mostly outside of the scope of HL7.
Grahame Grieve (Oct 11 2018 at 20:50):
some technical standards needed to support that eco-system
Jeffrey Danford (Oct 11 2018 at 20:57):
@Cooper Thompson the EHR vendors do offer review and certification services for applications but, at least for Allscripts, it's optional. We offer it for precisely the reasons you state and publish the list of certified applications to our clients.
Abbie Watson (Oct 11 2018 at 21:00):
right. but beyond that... what is needed to empower patients? What technical standards are needed to help the policy process, and then, what else is needed beyond that
Ohoo... we have some ideas on this. Big things first requiring SMART on FHIR type infrastructure.... something akin to a patient launch context, or a patient share, or patient initiated sync (and reconciliation).
Use case 1: Patient has been tracking their biometrics offline, and have 3 months of data to sync back to the hospital.
Use case 2: Patient moves between health networks (move between states/countries; new job; new insurance; etc) and wants to sync their health record to their new provider's EHR.
Use case 3: Patient gets a second opinion consultation from a practitioner who has a different interpretation of the medical condition. Second practitioner has a different selection of data points they consider relevant and important. Patient wants to highlight them and share with others from their PHR.
Cooper Thompson (Oct 11 2018 at 21:05):
@Jeffrey Danford Epic also offers review and certification services. However those services only apply to applications that choose to have a direct relationship with Epic. This approach means a single app would need to work with each EHR vendor individually to get certified.
Cooper Thompson (Oct 11 2018 at 21:06):
Having a single/central certification authority that EHR vendors could rely on means that apps could only go through certification once and have that apply to all (or most) EHR vendors.
Abbie Watson (Oct 11 2018 at 21:09):
Isn't HSPC basically positioned to be that central repository / authority?
Grahame Grieve (Oct 11 2018 at 21:10):
HSPC wants to be, but it's other people's opinions that make it so. What we can say for sure is that HL7 won't be the authority, but will support the process with technical standards.
Grahame Grieve (Oct 11 2018 at 21:11):
Use case 1 etc
yes, this is the kind of thing I want to see - a group pushing for wider set of use cases and making sure there's standards support
Lloyd McKenzie (Oct 11 2018 at 22:38):
Also, technical standards for users being able to say "this data in your clinical system is wrong" and allowing for clinical review before a change is applied. (On the premise that while clinical systems might be open to receiving patient-reported data, they're probably not going to allow unfettered patient-editing of the clinical record while at the same time, patient's are going to want to be able to initiate correction of inaccurate data.
Lloyd McKenzie (Oct 11 2018 at 22:41):
Technical standards around Provenance so that when a patient "syncs" their data with a new provider organization, it's clear what data came from other clinicians (and who), what data is patient reported and what data came from other clinical systems but has been patient-adjusted.
Abbie Watson (Oct 11 2018 at 22:45):
That's going to be huge. We're already excited about color coding all the different types of data. patient-reported, physician-reported, medical device, wearable, diagnostic laboratory, calculated-value, etc. Aside: Do we have a value set on that by the way?
Lloyd McKenzie (Oct 11 2018 at 22:47):
No value set on that yet to my knowledge. And your proposed value set is going to have some grey areas. When is something a medical device vs. a wearable? If a patient submits their wearable data, is that patient-reported?
Joel Schneider (Oct 11 2018 at 22:47):
DirectTrust is a currently available secure messaging system for integrating siloed healthcare data.
They already have a network of accredited Health Integration Service Providers (HISPs) for connecting systems to the Direct exchange. Communications between HISPs utilize encrypted email (S/MIME). Many healthcare institutions are already connected via the Direct exchange.
Not sure about the exact status of their FHIR support, but they are working on that, and were present at the last connectathon.
@Scott
Joel Schneider (Oct 11 2018 at 22:48):
https://www.directtrust.org/about-directtrust/
Abbie Watson (Oct 11 2018 at 22:57):
Some gray area, but I think we can provide some descriptive guidance to make it fairly discrete. Distinction between medical device and wearable could be well defined as whether or not it has a calibration state before each measurement, or whether it's real-time and streaming. And if the patient manually enters the wearable data, that's generally understood to be patient-reported. (We had to deal with this issue with Radiology diagnostic/referential images, wherein a flat-bed digitized scan of an analog radiograph was tagged by the file clerk rather than the RadTech.) But if the wearable data were to go directly into the PHR, then it would be tagged as wearable.
For what it's worth, there's some really interesting and relevant literature from Jean Baudrillard on data provenance and the classification of images (Simulacra et Simulation, 1981). We could assemble a value set for this topic that has some published and credible precedent.
Abbie Watson (Oct 11 2018 at 23:26):
I'm so going to write a blog post on this. I've got a whole white paper of things to say on this topic.
Grahame Grieve (Oct 11 2018 at 23:35):
btw, I believe that the single biggest deal for patient empowerment is not actually about the patient: it's to get the primary care provider to be part of the care team, not outside of it
Nick Hatt (Oct 12 2018 at 01:59):
How many users in FHIR Zulip represent provider organizations? I like what @Cooper Thompson says. Patient authorized-apps don't fall under HIPAA unless they are somehow part of a covered entity. Provider organizations need to balance empowering patients and preventing phising/cambridge analytica style breaches.
To @Michele Mottini's original complaint, provider organizations ultimately buy the software that can ultimately empower patients, if they were asking for consistent FHIR and SMART app launch support we'd have it. I imagine that's why Epic is the "best" - because they have some pretty big and vocal and customers who are also active in HL7.
Michele Mottini (Oct 12 2018 at 02:45):
Providers must allow patient to access their own data with an application of their choice - so if a patient ask for app X the provider must allow it
Josh Mandel (Oct 12 2018 at 03:40):
I love this discussion (just getting caught up here after a day of travel). My personal perspective is that for patient-facing apps, vetting (and eventually, moving from individual vendor vetting to centralized vetting) will be hugely important -- but it needs to remain technically optional if we're going to fulfill the vision of patient choice. Which is to say, vetting needs to actually demonstrate value for patients, meaning patients must be able to step around it (i.e., run unvetted apps) if they don't perceive value.
Josh Mandel (Oct 12 2018 at 03:43):
And on registration: one aspect of vendor-centralized registration is the sheer number of vendors in the long tail -- but I agree this is a secondary concern (i.e. if we can solve the others problems outlined here, developing an app with really wide reach becomes a quite possible, even if it's still a lot of effort to maintain hundreds of registrations).
Josh Mandel (Oct 12 2018 at 03:47):
I'm so excited to reach the point where we start working through next-level capabilities like submission of data and annotations on data.
Abbie Watson (Oct 12 2018 at 05:00):
(deleted)
John Moehrke (Oct 12 2018 at 15:24):
I have found that Patient Empowerment is well aligned with the overall set of Principles of Privacy. Too often Privacy is seen as nothing but confidentiality and Consent. It is far more than that. The OECD Privacy Principles are as good as any to review
- Collection Limitation Principle -- There should be limits to the collection of personal data and any such data should be obtained by lawful and fair means and, where appropriate, with the knowledge or consent of the data subject.
- Data Quality Principle -- Personal data should be relevant to the purposes for which they are to be used, and, to the extent necessary for those purposes, should be accurate, complete and kept up-to-date.
- Purpose Specification Principle -- The purposes for which personal data are collected should be specified not later than at the time of data collection and the subsequent use limited to the fulfilment of those purposes or such others as are not incompatible with those purposes and as are specified on each occasion of change of purpose.
- Use Limitation Principle -- Personal data should not be disclosed, made available or otherwise used for purposes other than those specified in accordance with Paragraph 9 except: a) with the consent of the data subject; or b) by the authority of law.
- Security Safeguards Principle -- Personal data should be protected by reasonable security safeguards against such risks as loss or unauthorised access, destruction, use, modification or disclosure of data.
- Openness Principle -- There should be a general policy of openness about developments, practices and policies with respect to personal data. Means should be readily available of establishing the existence and nature of personal data, and the main purposes of their use, as well as the identity and usual residence of the data controller.
- Individual Participation Principle -- An individual should have the right:a) to obtain from a data controller, or otherwise, confirmation of whether or not the data controller has data relating to him; b) to have communicated to him, data relating to him within a reasonable time; at a charge, if any, that is not excessive; in a reasonable manner; and in a form that is readily intelligible to him; c) to be given reasons if a request made under subparagraphs(a) and (b) is denied, and to be able to challenge such denial; and d) to challenge data relating to him and, if the challenge is successful to have the data erased, rectified, completed or amended.
- Accountability Principle -- A data controller should be accountable for complying with measures which give effect to the principles stated above.
It isn't even as simple as these 8 Privacy Principles. There are regional nuances, personal decisions, concerns for safety/health, etc. Often times there is complaints that these Privacy Principles get in the way of Medical Ethics the actual cases of conflict are few and usually well understood by those affected.
I have a more detailed article https://healthcaresecprivacy.blogspot.com/2015/04/privacy-principles.html
John Moehrke (Oct 12 2018 at 15:26):
Also detailed here https://healthcaresecprivacy.blogspot.com/2018/07/privacy-and-security-considerations-for.html
Specific adds: ability to delegate access to a care giver, spouse, parent, child, etc.
John Moehrke (Oct 12 2018 at 16:06):
A good example is the CarePlan work being done at FHIR Connectathons and IHE Connectathons. This last FHIR Connectathon they integrated the Consent and Break-Glass stuff, and had representation from Patient Portals to help show how the Patient can actively participate and contribute to their own CarePlan. http://wiki.hl7.org/index.php?title=201809_Care_Plan
Grahame Grieve (Oct 31 2018 at 19:39):
@Didi Davis @Peter Bernhardt Can you comment on where Carequality and Commonwell are with regard to patient access to data? My impression is that it's not on the road map - am I correct?
Didi Davis (Nov 02 2018 at 14:56):
@Grahame Grieve I checked in with the leadership of both Carequality and Commonwell and have the following updates to provide based on your question. From Dave Cassel, Executive Director for Carequality: "Both Carequality and CommonWell support patient access to data, and enhancing these capabilities is definitely on both roadmaps. I can’t speak any more specifically to CommonWell than that, but can elaborate a bit for Carequality. Today, Patient Request is one of the “permitted purposes” supported for query-based document exchange. Carequality is working actively on enhancing its policies to enable wider support for exchange under this permitted purpose. As we develop the policies and supporting technical components to enable FHIR-based exchange via Carequality, we fully expect that patient access use cases will be a critical part of the solution. Generally, as Carequality develops any new capability, consumer participation is always a consideration."
Didi Davis (Nov 02 2018 at 15:02):
@Grahame Grieve II checked with Jitin Asnaani, Executive Director from Commonwell and have the following update to provide from him: "Patient Access to data is an approved and implemented use case – i.e., support for it is built into our network infrastructure. In fact three PHRs are already connected for that purpose. Furthermore, all participants on the CommonWell network are required to respond to Patient Access requests. However, in practice, the three PHRs who have connected thus far are in limited deployment/alpha, and the number of transactions that they have enabled amount to far less than 1% of our total transaction volume. As CommonWell Adopters join the Alliance and are able to connect to Alliance services, we hope to see that volume go up. In terms of our role as a Carequality Implementer, for the moment we are only accepting Treatment transactions from other Carequality implementers, as there are security and other considerations for other “permitted uses” that we simply have not reviewed as yet."
Grahame Grieve (Nov 02 2018 at 21:19):
thanks. I feel as though this is allowing access via selected PHRs rather than direct access for patients via an API....?
Grahame Grieve (Nov 05 2018 at 20:10):
https://twitter.com/IrmaRaste/status/1059267154686570498 :-)
John Moehrke (Nov 06 2018 at 18:33):
thanks. I feel as though this is allowing access via selected PHRs rather than direct access for patients via an API....?
The problem that must be covered by someone is Identity Proofing of those patients, to assure that they are a User who is the Patient or are an authorized agent of the Patient. This functionality is the hard part, especially in the USA where we have no common or universal identifier. There have been discussions about organizations like the US Post Office taking on this identity proofing role. If they did, then federated-organizations like the eHealth Exhange, CareQuality, or CommonWell could rely on that identity.
John Moehrke (Nov 06 2018 at 18:36):
In theory, the EHR that has a Patient Portal could be an enabling point for the Patient to access any data available on the Exchange. That EHR Patient Portal has done identity proofing of the user to that Patient identity within the EHR, so transitory it should be good-enough for all partners. Based on the fact that all Partners in the exchange already trust queries on that Patient Identity are equivalent. Is anyone doing this?
Grahame Grieve (Nov 21 2018 at 03:18):
Follow up : If you're interested in being involved in a specific patient track for FHIR activities, and/or a patient/consumer focus group at HL7, please like this post, and we'll pass you name on to Dave Bronkhart
Dave deBronkart (Nov 21 2018 at 23:32):
I'm here! I'm here! Trying to figure out where the light switches are... I've been debating what keywords I should set up a search for. I imagine "patient" is far too broad. (Is this the right place to discuss that?)
Seriously, in Amsterdam at least two people came up after my talk and said they were DOING what I proposed are CHANGING what they're doing to spin off a patient "flavor" of their app. WHO ARE YOU? Who else wants to discuss??
Dave
Meta: The name's deBronkart, btw ... some ancestor removed the space in the Belgian "de Bronkart" (or bronckaert, etc, depending on which document you trust.
Lloyd McKenzie (Nov 22 2018 at 00:17):
Welcome to the community Dave :) This is a fine place to discuss keywords, though we generally don't pay too much attention to those. They manifest naturally out of the discussions and we also have lots of people to direct others on where to go when they ask questions. At some point, we might set up a separate stream, but for now I'd probably hang out on the #implementers and #patient empowerment (though discussion there hasn't really gotten off the ground yet).
Grahame Grieve (Nov 22 2018 at 03:35):
I forgot about that stream...
Grahame Grieve (Nov 22 2018 at 03:36):
and apologies on the name
Mario Hyland (Sep 16 2019 at 20:38):
As a follow up to our recent conversation with Dave deBronkart - as we engage with the Patient community regarding FHIR accessible applications and devices, we would benefit this group with regard to FHIR Testing by looking for ways to provide similar to "Crash Test Results" in the automotive community if we find a way to publish"FHIR Conformance Results" from FHIR Implementers (vendors and organizations) so both App Implementers and Patients could review. Touchstone-AEGIS-WildFHIR-FHIR-Testing-Conformance-Test-results.jpg
Dave deBronkart (Sep 16 2019 at 20:46):
Funny, @Mario Hyland, you found the ancient Patient Empowerment thread in the #social stream.
You might want to re-post this to the #patient empowerment stream. :slight_smile: (And thanks for contributing)
Last updated: Apr 12 2022 at 19:14 UTC
