Stream: connectathon mgmt
Topic: C16 Consumer Centered Data Exchange
John Moehrke (Aug 30 2017 at 20:42):
Starting a chat thread for the Consumer Centered Data Exchange track at Connectathon 16 http://wiki.hl7.org/index.php?title=201709_Consumer_Centered_Data_Exchange
Grahame Grieve (Aug 30 2017 at 20:44):
thanks. @Aaron Seib - just to et you know
Aaron Seib (Aug 30 2017 at 21:05):
Thanks John and Grahame.
John Moehrke (Aug 30 2017 at 21:40):
First Question: Are we going to rally our connectathon track around the AHIMA "Patient Request for Health Information"? https://engage.ahima.org/HigherLogic/System/DownloadDocumentFile.ashx?DocumentFileKey=65a95abe-c892-2e4a-7012-d1f8e7fa740e&forceDialog=0
John Moehrke (Aug 30 2017 at 21:43):
If so, then I think this form would produce a CommunicationRequest and a Consent. Th Consent would authorize the CommunicationRequest, but the CommunicationRequest would be the thing that explains where and what is being asked to be forwarded to whom. See attached... AHIMA-Mapping-FHIR-20170830.pptx
Grahame Grieve (Aug 30 2017 at 21:47):
how would a communication request be useful?
Grahame Grieve (Aug 30 2017 at 21:47):
and the connectathon track is not about form either.
John Moehrke (Aug 31 2017 at 12:18):
The connectathon track and the AHIMA form are a request by a Patient to have their data at site to be communicated to another site (where that site might be their own PHR)... That is my understanding.. and hence why I ask the question before I go further down this pathway
John Moehrke (Aug 31 2017 at 12:30):
The connectathon track has 8 patterns. Of those participating, which one or two do we have enough participation to complete? We can't have everyone working on a fraction of different patterns...
Grahame Grieve (Aug 31 2017 at 20:54):
That's a good question. I don't know what the answer is. In fact, I suspect that the main function will be to shake down the patterns.
Michele Mottini (Sep 01 2017 at 14:53):
I am not really sure in which circumstances you would use those...
The way it works now is:
1) Patient has login on provider portal - so provider / patient already did the necessary paper work / identity proofing to get that
2) App (that can be patient own PHR or other EMR) connect to SMART-on-FHIR end point
3) Patient sign in with their credentials and authorize app access to the data as part of the SMART-on-FHIR authentication and authorization sequence
4) App gets the data using FHIR
John Moehrke (Sep 01 2017 at 15:31):
Michele, I am happy to not further develop the AHIMA form. I looked at it because it was suggested in one of the many sub-scenarios... I can certainly work with your flow. But your flow seems far more simply SMART-on-FHIR. Where is the Consent in your flow? Where is the enabled data exchange?
Do you have a consent form in mind? I am here, as SME on the FHIR Consent and as co-chair of the security wg, to help the group understand our intended use, and to take lessons learned back to improve the FHIR standard... So I don't care which scenario we work on. I just want it to be something more than has been shown many times as classic SMART-on-FHIR... I want to engage the Consent resource.
Michele Mottini (Sep 01 2017 at 15:47):
Yes, I guess my question is why (or in which circumstances) do we need a consent form?
The simple SMART-on-FHIR flow seems to cover all that's needed (?) - and simple is good
John Moehrke (Sep 01 2017 at 15:48):
Yes, if one can use simple... then one should use simple...
John Moehrke (Sep 01 2017 at 15:52):
and if all we want to achieve is SMART-on-FHIR being used by a Patient rather than only Providers... then that is an improvement too... I have tried to fight that misinformation https://healthcaresecprivacy.blogspot.com/2017/04/fhir-security-model-is-enterprise.html
John Moehrke (Sep 01 2017 at 15:55):
Im looking similarly at the MiHIN Behavioral Health Consent form http://www.michigan.gov/mdhhs/0,5885,7-339-71550_2941_58005_70642---,00.html It seems much more like a normal Consent form, authorizing Sharing. And because of the vectors in the form, it will leverage the FHIR Consent model quite nicely.
Grahame Grieve (Sep 01 2017 at 18:53):
the point of the connectathon stream is to enable a patient to get institutions to share data about the patient directly with each other
Grahame Grieve (Sep 01 2017 at 18:53):
data shared between them via the patient is a very different exchange than directly between them
Grahame Grieve (Sep 01 2017 at 18:54):
classic smart on fhir is a 2 way exchange. we're looking at a 3 way exchange here
Michele Mottini (Sep 01 2017 at 19:05):
Mhh.. I don't understand - for example scenarios 1 and 2 at http://wiki.hl7.org/index.php?title=201709_Consumer_Centered_Data_Exchange seems identical - except that the second adds a consent - but I don't understand what's the purpose of that (nor the mechanics of it) - the patient is already consenting to the data transfer using SMART-on-FHIR
Grahame Grieve (Sep 01 2017 at 19:44):
in scenario 1, the target EMR must be registered as an application with the source EMR
Grahame Grieve (Sep 01 2017 at 19:45):
in scenario 2, registration is not required. the patient's application must be registered with both, but they don't need to be registered with each other
Michele Mottini (Sep 01 2017 at 21:00):
ah ok, got it, now I see the difference
Alan Viars (Sep 09 2017 at 16:31):
Hello. Pleas send me your name, email and company affiliation to receive a developer invite to the dev/test environment for CMS Blue Button API.
Michele Mottini (Sep 09 2017 at 16:55):
Anybody from DXC here? Would like to try to connect to your FHIR end point
Jason Walonoski (Sep 09 2017 at 17:48):
Here is what I'm going to do for this track... build a patient facing SMART-on-FHIR App to:
1. reads my patient record from Cerner
2. lookup another provider using provider directory, along with FHIR endpoint
3. transfer my patient record to new provider
Reuben Daniels (Sep 09 2017 at 17:50):
Jason: how does the Consent resource fit into that?
Jason Walonoski (Sep 09 2017 at 17:50):
@Reuben Daniels It doesn't right now. Patient consent is built into the patient actions.
Michele Mottini (Sep 09 2017 at 17:51):
Cool.
Who'll play the new provider? Are you going to POST the data to the FHIR end point to transfer it?
Jason Walonoski (Sep 09 2017 at 18:04):
Yes. I'm going to use HAPI DSTU2, because Cerner is still sending DSTU2 records. I'm going to use Brian's healthconnex as the provider directory.
Michele Mottini (Sep 09 2017 at 18:08):
...you can try to POST on our server as well .. although we will not show up on the provider directory...
John Moehrke (Sep 09 2017 at 18:15):
FYI: Here is a blog article I wrote last night as a proposal for what we could do this weekend. https://healthcaresecprivacy.blogspot.com/2017/09/remedial-fhir-consent-enforcement.html
Brian Postlethwaite (Sep 09 2017 at 19:02):
You could also directly post the results of your $everything from the patient to my DSTU2 server too.
Brian Postlethwaite (Sep 09 2017 at 19:02):
http://sqlonfhir-dstu2.azurewebsites.net/fhir
Julie Maas (Sep 09 2017 at 21:09):
We can provide a data source for the existing provider data pull--please visit our table for server connection info. Thanks!
Michele Mottini (Sep 09 2017 at 21:32):
@Julie Maas : I am remote - can you post sever connection info here?
Julie Maas (Sep 09 2017 at 23:14):
Yes I will get that for you. Can you do dynamic client registration?
Michele Mottini (Sep 09 2017 at 23:15):
Not currently, but I can surely try
Julie Maas (Sep 09 2017 at 23:27):
Here you go Michele (or others who want to try this as a source): https://sandbox.interopengine.com:8181/fhir-server-stu3/emrdirect-test-ehr
Michele Mottini (Sep 09 2017 at 23:34):
HTTPS cert is not valid
Michele Mottini (Sep 09 2017 at 23:44):
I am POSTing:
Michele Mottini (Sep 09 2017 at 23:44):
{
"redirect_uris": [
"http://localhost:49322/PDemo.html"],
"token_endpoint_auth_method": "none",
"client_name": "PDemo"
}
Michele Mottini (Sep 09 2017 at 23:44):
to https://sandbox.interopengine.com:8181/oauth/register to register my client - I get back an error:
Michele Mottini (Sep 09 2017 at 23:44):
{
"error": "invalid_client_metadata",
"error_description": "Client registration metadata malformed or invalid."
}
Michele Mottini (Sep 09 2017 at 23:45):
does not seem malformed to me - maybe your server requires some more data?
Julie Maas (Sep 09 2017 at 23:53):
Are you treating your client as a public client or a confidential client?
Michele Mottini (Sep 09 2017 at 23:53):
Public
Julie Maas (Sep 10 2017 at 00:18):
looks like we are not allowing dynamic reg of public clients for this event. Are you able to register a confidential client with an https redirect_uri? If not, we'll see what we can enable for tomorrow.
Michele Mottini (Sep 10 2017 at 01:11):
I was able to register another application that uses https and support client secret
Michele Mottini (Sep 10 2017 at 01:12):
...but now I get an error trying to connect: it seems that your end point does not support CORS
John Moehrke (Jan 26 2018 at 23:01):
New C17 track builds on prior. See http://wiki.hl7.org/index.php?title=201801_Consumer_Centered_Data_Exchange
Sandeep Giri (Jan 26 2018 at 23:26):
Are we planning to do a brief track meeting tomorrow morning to go over the 3 different "architecture" description provided in the wiki, and also the word doc that describes the test environment?
Sandeep Giri (Jan 30 2018 at 01:31):
Great video put together of the Connectathon track update report - https://vimeo.com/253352106
Sandeep Giri (Jan 30 2018 at 01:43):
Quick question to folks from MiHIN, New Wave, and DXC:
When MiHIN and New Wave share their patient consent information with DXC's Resource Server (RS), do they send a FHIR Consent resource to DXC, which the DXC's RS stores in its own framework to validate request access from clients like DXC Record Viewer, CilnFHIR, and Humetrics? Or, is DXC's RS make a call in real-time to MiHIN or New Wave to check for patient consent each time the DXC RS gets a client request?
Also, how does it know which FHIR resources are covered by which consent directive? Does it need to keep track of resources whose access is governed by consents provided by MiHIN vs New Wave vs DXC's own Consent Manager?
Sandeep Giri (Jan 30 2018 at 01:43):
And a question to folks from ClinFHIR and Humertrics:
When your client calls DXC's RS, does the client have to do anything special regarding managing consent, or does the client delegate all the responsibility to DXC's RS? In other words, as a client, do you care which records you have access to? Wouldn't you just ask for FHIR resources on behalf of a patient, and expect the RS to check for patient consent before sending those resources back to your client?
Sandeep Giri (Jan 30 2018 at 01:48):
@David Hay @Aaron Seib @Patrick M
David Hay (Jan 30 2018 at 02:02):
yep. As a client, I authenticate to the RS (via the AS), then send normal FHIR queries to the RS. I do send the role, purpose and organization in the call (in an HTTP header) which is what the back end systems use (in conjunction with the Consent) to decide what to return to me. The way we send the role/purpose/org does need to be standardized I feel (currently they are in a comma delimited string).
John Moehrke (Jan 30 2018 at 14:16):
I started a profile (constraints on Consent) that defines what the DXC solution currently supports. It s just a work in progress, a scratchpad... This s what it looks like on Simplifier. More work needed to defined further vocabulary constraints. https://simplifier.net/AuditEventforRESTque/DHPconsent
Bo Dagnall (Jan 31 2018 at 23:59):
Hi. Bo Dagnall from DXC here. We have a working implementation of a consent manager, resource server with consent processing capabilities and a security labeling service. All of this was used at the Connectathon. We are excited to work you all. Please let me know if and how you would like to connect
Bo Dagnall (Feb 01 2018 at 00:00):
Anybody from DXC here? Would like to try to connect to your FHIR end point
Bo Dagnall from DXC here. We are happy to connect with you. bo.dagnall@dxc.com
Sandeep Giri (Feb 01 2018 at 18:01):
thanks @John Moehrke - I noticed you scratched out "consentingParty" -wouldn't we want to include this to track who is the consent intended for? IOW, I understood that "consentingParty" is how a patient/user can designate sharing with a specific app or organization - no?
Sandeep Giri (Feb 01 2018 at 18:06):
thanks @Bo Dagnall - your examples were very helpful to understand some simple options for implementing this. I imagine your architecture assumes an independent Consent Server (CS) that is being consulted by many different FHIR Resource Servers (RS). In that sense, does the RS then poll the CS each time it receives a resources request (to check if the patient has consented to sharing)?
Sandeep Giri (Feb 01 2018 at 18:10):
very interesting @David Hay - thanks for clarifying. What could be some options for standardizing the sending of role, purpose, and org? Could this be done via OAuth tokens?
Bo Dagnall (Feb 01 2018 at 18:31):
I am posting an email exchange between Sandeep as it is relevant to this discussion:
When MiHIN and New Wave share their patient consent information with DXC's Resource Server (RS), do they send a FHIR Consent resource to DXC, which the DXC's RS stores in its own framework to validate request access from clients like DXC Record Viewer, CilnFHIR, and Humetrics? Or, is DXC's RS make a call in real-time to MiHIN or New Wave to check for patient consent each time the DXC RS gets a client request?
[Dagnall, Bo] It can work either way, but for the Connectahon, the DXC Consent Manager pushed a consent resource into the RS every time the patient updated their consent entries. For the MiHIN consents, the DXC RS fetched the consent resources every 30 seconds. This is configurable.
Also, how does it know which FHIR resources are covered by which consent directive? Does it need to keep track of resources whose access is governed by consents provided by MiHIN vs New Wave vs DXC's own Consent Manager?
[Dagnall, Bo] The governance authority of a consent resource was not considered during the Connectathon. Thus, all consents were treated equally regardless of source. However, we did have login in place to avoid conflicting consents. If DXC recorded a consent then MiHIN sent a more recent consent, the MiHIN consent overrode the prior consent. Our DXC Consent Manager UI will update to show the updated consent provisions sent from MiHIN. In a real-world implementation, we would need to have mechanisms in place to handle different consent authorities.
And a question to folks from ClinFHIR and Humertrics: When your client calls DXC's RS, does the client have to do anything special regarding managing consent, or does the client delegate all the responsibility to DXC's RS? In other words, as a client, do you care which records you have access to? Wouldn't you just ask for FHIR resources on behalf of a patient, and expect the RS to check for patient consent before sending those resources back to your client?
[Dagnall, Bo] Yes, the RS handles all the consent checking and redaction prior to sending the data back to the client. The client has no responsibility for knowing what is sensitive or for handling sensitive or restricted information.
David Hay (Feb 01 2018 at 20:16):
wrt how to send the role and other stuff, I'd have to defer to the OAuth experts. But, I understand that the WG is looking at making the scope token richer, so that might be an option...
John Moehrke (Feb 01 2018 at 20:25):
@Sandeep Giri the profile is a representation of what is currently coded. Not necessarly the goal, just what they needed today. Many times when we removed an element, I captured a note as to why. In this case I don't see that I captured a note. @Bo Dagnall do you have a comment?
Bo Dagnall (Feb 02 2018 at 17:47):
What John said is correct wrt to our implementation of the Consent resource. We had to make assumptions about what provided the most value for the Connectathon. We elected to focus on patient, organization, policy (opt in or out), and exceptions (deny or permit) based on actor (which we interpreted as role), purpose of use and security label. We did not apply security labels at the overall consent level just at the exception level. Over the weekend, we had discussions about including consenting organization so we can manage business rules to process consents from different organizations and also including provider name to be able to define exceptions at the individual person level. Grahame Grieves also talked to me about how the value sets for purpose and for security label overlap. He explained the need to differentiate between saying that the purpose of use is, for example, "behavioral health" and the security label tags the data under the category "behavioral health". I suppose it is possible that someone could permit data for the purpose of behavioral health and then deny access to behavioral health data given this duality. We need to better understand the best way to handle these value sets in relation to each other.
Bo Dagnall (Feb 02 2018 at 17:51):
thanks @Bo Dagnall - your examples were very helpful to understand some simple options for implementing this. I imagine your architecture assumes an independent Consent Server (CS) that is being consulted by many different FHIR Resource Servers (RS). In that sense, does the RS then poll the CS each time it receives a resources request (to check if the patient has consented to sharing)?
@Sandeep Giri At this point, we make no assumptions about the consent server. We effectively have a configurable tool that can either push or pull consents from one or more sources. If pulling, OHC (our resource server) can pre-fetch and cache or pull dynamically. If these is a designated authority for consent resources, we can configure our solution to point to that only. Alternatively, we can consider defining business rules that allow us to handle consent from multiple authorities and understand how to process them accordingly. In this scenario, we need guidance from the community on what those business rules should be. Interesting topic...
Sandeep Giri (Feb 02 2018 at 21:52):
Thanks @Bo Dagnall -- I'm interested in outlining the implementation of a rather simple scenario where a patient is authorizing/consenting a specific care provider to share their health records with a specific 3rd party app controlled by the patient (for example - I as a patient want to authorize/consent my care provider UCSF to share my health records with a digital health app on my iPhone, or HealthKit).
In that scenario, most likely the resource server, authorization server, and the consent server, will be all provided/managed by UCSF (I understand that it doesn't have to be this way, but I'm trying to outline a simple way for a provider to share data with apps without jumping through many hoops). As such, when I tell my iPhone app to go get my health records from UCSF, UCSF's authorization server can then pop up a challenge for me to log into UCSF's patient portal, and when I do so, UCSF can "record" the app as a trusted 3rd party (app) controlled by a trusted patient (me). Now, UCSF may additionally want to ask me how much of my health records do I want to share with this app -- everything, nothing , or everything that is not marked "restricted" or "very restricted", and record my response as my authorization/consent on record so that anytime this particular app asks for my data, UCSF can consult my preference and decide what it can share.
Assuming this interaction makes sense, I'm curious if the "consentingParty" attribute is the right place to define the specific app with whom the patient has authorized or consented to sharing of their health records.
Aaron Seib (Feb 04 2018 at 19:55):
David - just trying to parse your statement here. Which WG is working to make the scope token richer? I've been trying to aggregate what I learned from the connectathon and think for some use cases and scenarios the token is going to need a have a greater role.
John Moehrke (Feb 04 2018 at 19:57):
@Sandeep Giri the app in that case would be in a Consent.provision.actor.reference (Device) as role 110150 (application)
John Moehrke (Feb 04 2018 at 19:57):
The app is not consenting, it is being given authority.
John Moehrke (Feb 04 2018 at 20:05):
@Bo Dagnall It is very true that the vocabulary used for security tags (the HCS) is made up of codes that have different meanings when used in different ways. Used in one way, tags on data, they indicate the kind of data (metadata), and thus point toward the kind of policy that would be used to protect them. A variant on this is the difference between sensitivity tags, and compartment tags; both are very similar yet discussed different. Used in a symmetric way, tags within a policy, to indicate the kind of data that policy applies to. Used an another way, tags on a transaction request, are an assertion of intent (meta-transaction), such as a promise t only use the result in a constrained way (e.g. PurposeOfUse). Used in yet-another way, as tags on a transaction full of data, as a condition of use (aka obligation). These four ways (metadata, policy tags, scope, and obligations) are all possible. I would like to suggest that when used in this way, it is clear what the meaning is. However there are some cases where there is mixed messages in documentation.
John Moehrke (Feb 04 2018 at 20:08):
@Aaron Seib HL7 is working on making normative the SMART-on-FHIR specification first defined by Argonaut, they have done one normative ballot, and are harmonizing to a first normative edition. This first edition will be as close to existing SMART-on-FHIR as possible, but along the way many comments (negative ballots) are being delayed to be considered during second version. It will be in this second version that scopes will be made more rich. This effort will not start until the first is finished, so we all have no idea where it will ultimately head, but we have all committed to do it.
Aaron Seib (Feb 04 2018 at 20:11):
Thanks @John Moehrke - Is it known who at HL7 is leading the effort on the second version?
John Moehrke (Feb 04 2018 at 20:12):
SMART-on-FHIR is a co work of FHIR-I and Security
Aaron Seib (Feb 04 2018 at 20:13):
@John Moehrke & @Sandeep Giri - what are your guys thoughts regarding the IG that we started at the connectathon? I think it is going to be immensly valuable and would like to get it out into the sunshine unless you guys think we should hold back?
John Moehrke (Feb 04 2018 at 20:25):
I don't think we got it far enough for it to be understood properly, right? It is important to make sure it is understandable by someone not present.
Grahame Grieve (Feb 04 2018 at 20:27):
smart on fhir is being balloted as trial use, not normative.
Grahame Grieve (Feb 04 2018 at 20:28):
@Sandeep Giri - I'm very interested in the use case of patient authorising sharing records between other cases directly too
Aaron Seib (Feb 04 2018 at 20:31):
I don't think we got it far enough for it to be understood properly, right? It is important to make sure it is understandable by someone not present.
```. I agree with you. I want to keep pushing it forward. I can set up a webinar for those interested to joining a working session to keep it going forward.
Sandeep Giri (Feb 05 2018 at 04:21):
thanks all -- @Aaron Seib , I think it will be beneficial to discuss the draft IG with perhaps the track participants over a webinar (and/or via the Google doc draft) .. will be great to iterate on it and publish it as an IG on simplifier.net
Aaron Seib (Feb 08 2018 at 22:08):
@Sandeep Giri Absolutely - NATE would be happy to host a webinar to go over what we started at the connectathon. I will sent out a note to see who'd be interested in attending such a working meeting.
Last updated: Apr 12 2022 at 19:14 UTC
