Stream: smart
Topic: C25 -- Testing with Epic
Josh Mandel (Sep 10 2020 at 14:47):
@Jake Fisher great to meet you on the check-in call just now. Re: testing with Epic, do you have a server online for "Scenario 1"? And can share details about how to get a client configured? When I follow links from the signup spreadsheet I end up at https://connectathon.epic.com/Interconnect-Fhir-OAuth/Login.aspx?ReturnUrl=%2fInterconnect-Fhir-OAuth%2fStatusPage%2fMain.aspx but I don't know how to sign in.
Jake Fisher (Sep 10 2020 at 14:53):
@Josh Mandel let me get a client set up. Would you like to test one with access to vital-signs Observations but not labs Observations, or something along those lines? Also what redirect_uri should I use for your "app"? I'll need to register those things statically.
Josh Mandel (Sep 10 2020 at 15:02):
Ideally it'd be good to test a client for Scenario 0 (including all observations) and Scenario 1 (so it can ask for patient/Observation.rs?category=vital-signs and get access to vitals but not labs). It sounds like that will require registering two separate clients?
Josh Mandel (Sep 10 2020 at 15:04):
For redirect URLS, if you can register http://localhost:8000/index.html and https://smart.argo.run/granular/ for both, that'd be ideal. (Gino might chime in and tweak that arog.run URL once things are up and running ;-))
Josh Mandel (Sep 10 2020 at 15:49):
OK, updated the second URL in the request above. @Jake Fisher just want to make sure you've seen this?
Jake Fisher (Sep 10 2020 at 15:57):
Yep I have and I'm working on creating clients for you to test with. We currently return our R4 resources with the existing SMART scope syntax (system | user | patient)/resource.(read | write), so I need to alter how we return this slightly to support this testing.
Josh Mandel (Sep 10 2020 at 15:58):
Awesome, that's what connectathon is for :-)
Jake Fisher (Sep 10 2020 at 15:59):
Also - FYI that we don't support dynamic scoping right now. The scopes that are statically registered for the client with the server is what it will have access to, regardless of what it requests at runtime.
Josh Mandel (Sep 10 2020 at 16:12):
Will this be clear in the token response? In other words can a client learn what it has been granted by looking up the Scopes array in the access token response?
Jake Fisher (Sep 10 2020 at 16:19):
Yes - the client will currently get a list of all the scopes they statically registered with us, regardless of whether or not they requested all of them. So this does accurately reflect what they have access to.
Jake Fisher (Sep 10 2020 at 16:20):
Almost done with the mock client record setup for you Josh.
Jake Fisher (Sep 10 2020 at 16:22):
Quick question about scenario 0: should the client have access to some interactions for Observation but not all? For example, read/search but not create? We already don't support GETing all Observations without supplying a patient (search interaction) or Observation ID (read) so this example in confluence seems a bit weird to me, but maybe I'm misinterpreting it.
GET Observation (as opposed to GET Observation?patient={})
I'll allow these scopes for the scenario 0 client for now (so create would not be allowed):
patient/Observation.rs
patient/Patient.rs
Max Philips (Sep 10 2020 at 16:28):
GET Observation in my experience tends to work on reference servers but not vendor servers :). I.e. for Cerner GET Observation also already does not work, so I didn't do any extra connectathon-specific implementation for that part
Josh Mandel (Sep 10 2020 at 16:33):
For scenario 0, we'd be happy with patient/Observation.r and patient/Patient.r I think.
Jake Fisher (Sep 10 2020 at 16:40):
Any concerns with user-facing clients instead of patient-facing? I have a test user already set up. I could set up a test patient with a patient portal account and some patient-facing clients as well if needed.
Jake Fisher (Sep 10 2020 at 16:41):
Details for the user-facing clients are in the spreadsheet now. Working on mocking up some test data so you can actually get some data haha.
Josh Mandel (Sep 10 2020 at 16:55):
Our scenarios are designed around patient-level scopes so we can try out restrictions by patient as well as category.
Josh Mandel (Sep 10 2020 at 16:55):
It'd be great if you're able to stay compatible with the scopes from Scenario 0 and Scenario 1
Josh Mandel (Sep 10 2020 at 16:56):
(Gino's working on a "playground" mode that'll let us more easily test things off the beaten path, but it'd be great to test things on the path first.)
Jake Fisher (Sep 10 2020 at 17:47):
Ok I updated the scopes for the 2 clients I created to be patient/*. Details are in the spreadsheet.
Josh Mandel (Sep 10 2020 at 18:43):
Thanks @Jake Fisher ! I'm making some progress in testing here. One issues is that at the end of the authz process, even though I asked for launch/patient and I'm granted patient/Observation.rs?category=vital-signs, the access token response isn't giving me a patient context param. For example I'm getting:
{
"access_token": "P51s2Ti9GLDZq4mn2RFatx3b3i27LrkGvpVrsksuQgYA6wxbBYsIosVDIuqG21BeO4bvz0ZiHUXe3YFZ8TGZ98qjNUni30Q1ibEAypyJUN9wx29ni2vtlSm5KRrh0isI",
"token_type": "bearer",
"expires_in": 3600,
"scope": "fhirUser openid patient/Patient.rs patient/Observation.rs?category=vital-signs",
"state": "LTFO5plq1H4Rlf7J",
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IkVRU2F0aDBEVU95Mzl3Rnk5ZDZ4Z0o2TThHMUFtR1Noc0ZRanplcjFFRUk9IiwidHlwIjoiSldUIn0.eyJhdWQiOiJDb25uZWN0YXRob24yMDIwT2JzZXJ2YXRpb25WaXRhbHMiLCJleHAiOjE1OTk3NjM2MzIsImZoaXJVc2VyIjoiaHR0cHM6Ly9jb25uZWN0YXRob24uZXBpYy5jb20vSW50ZXJjb25uZWN0LUZoaXItT0F1dGgvYXBpL0ZISVIvUjQvUHJhY3RpdGlvbmVyL2VVNk1NRUxVemdGMzBYcVZwMFZsQVNRMyIsImlhdCI6MTU5OTc2MzMzMiwiaXNzIjoiaHR0cHM6Ly9jb25uZWN0YXRob24uZXBpYy5jb20vSW50ZXJjb25uZWN0LUZoaXItT0F1dGgvb2F1dGgyL3Rva2VuIiwic3ViIjoiZVU2TU1FTFV6Z0YzMFhxVnAwVmxBU1EzIn0.jQ3HZ8jb7RAwV9chP3QU-_uzKJs4dh7IrPRrU3chds0x0Ltd4uCYChMcYJuFpM8M7EUyaFN1LL3Tf4aSCibePz02lTRG3qNCtz5Cv4inOhtjqnWTONIf2TrZo1MkUP7oJtQzwTCEeNrp6zLGzq8jgpP-uBU4N9ZAPds8N6JpCjmsVy0wLqOkXJueCuGAHlzshdJ3QWs3c73xb1Lz-Th8cLEDBevvusb_9kXbScW2SNuuGKR03aQyBXplamcOTATdvZVpS0hGv25eH4gqz6wtqEeoCBF_5Y90R-bhmKk-lh-G4L3-VFoAfelHkxLfWEDUAsTNNjqz1US-A-BZfI9ebQ"
}
Jake Fisher (Sep 10 2020 at 18:57):
We don't support launch/patient yet. Right now (for connectathon) this is basically a user-facing standalone launch, though the scopes are prefixed with patient. Working on getting an actual patient-facing standalone launch set up for this, in which case you'd get the patient ID along with the access token.
Josh Mandel (Sep 10 2020 at 19:07):
OK, that'll be really helpful when patient launch is in place (it's basically what we designed our scenarios around).
Jake Fisher (Sep 10 2020 at 19:21):
Ok these clients will now use true patient-facing standalone launch. Please try again. I've put the patient portal login information in the spreadsheet.
Josh Mandel (Sep 10 2020 at 19:23):
Awesome!
Josh Mandel (Sep 10 2020 at 19:24):
I've got the end-to-end test running now. Thanks @Jake Fisher !
Jake Fisher (Sep 10 2020 at 20:59):
Whoops realized just now that the Connectathon2020AllObservations client wasn't actually allowed to search Observation?category=vital-signs (it was allowed to read them and to search other observation categories). That's updated now.
Pascal Pfiffner (Sep 10 2020 at 21:50):
Wow Jake, that's a nice & scary auth screen :)
Pascal Pfiffner (Sep 10 2020 at 21:56):
Nice – same here, end-to-end tested!
I tried Observation?patient=eH8RPbKOmYpNJoL9ha.Uq9A3 and that gave an operation outcome with "required parameter missing" or similar
And I tried Observation?patient=eH8RPbKOmYpNJoL9ha.Uq9A3&category=vital-signs and that gave me a bundle of vitals
And I tried Observation?patient=eH8RPbKOmYpNJoL9ha.Uq9A3&category=laboratory and that gave me an empty bundle
Jake Fisher (Sep 10 2020 at 22:00):
@Pascal Pfiffner yep - though it doesn't look as scary if developers fill out a data use questionnaire which is shown to patients instead. I didn't do that for these connectathon clients. :)
Pascal Pfiffner (Sep 10 2020 at 22:00):
Yeah that's what I assumed; but I like it, it should be scary!
Keith Carlson (Sep 11 2020 at 12:59):
I'm getting an invalid_request when I try and hit the token endpoint using:
curl -i "https://connectathon.epic.com/Interconnect-Fhir-OAuth/oauth2/token" -H "Content-Type: application/x-www-form-urlencoded" -H "Accept: application/json" --data "code=sYChMYd9WlCxjmYaV60IW48W1vR69_g3KIcA8XIcuHGofzhVTtJbvfeik60ApbcfQvl8mVzm7J9wsltZ2hG_NA8ia2F2RQ4DFYuPF4j2Cbn5iRj0GpraskxGoWZ1xKKH&grant_type=authorization_code&redirect_uri=http://localhost:8000/index.html"
Any ideas what I am missing here?
Jake Fisher (Sep 11 2020 at 14:08):
@Keith Carlson How did you get that auth code? Those are one time use and only valid for a short amount of time (a few minutes).
Keith Carlson (Sep 11 2020 at 14:13):
I got the auth code by using https://connectathon.epic.com/Interconnect-Fhir-OAuth/oauth2/authorize?client_id=Connectathon2020AllObservations&scope=launch/patient&response_type=code&redirect_uri=http://localhost:8000/index.html and grabbing it from the uri
And yeah I figured it was short lived, when I was trying to exchange the code for the token I was doing that within a few minutes and still running into the invalid_request
Jake Fisher (Sep 11 2020 at 14:14):
Ok thought it was worth a check. I'll take a look.
Keith Carlson (Sep 11 2020 at 14:16):
Okay, thanks. The curl command I was using looks good to you? Not sure if I'm missing something small there. It seems like other people are able to connect
Jake Fisher (Sep 11 2020 at 14:32):
Ah - you need to pass the client_id in the body. I just added that to my CURL request and it's working.
curl -i "https://connectathon.epic.com/Interconnect-Fhir-OAuth/oauth2/token" -H "Content-Type: application/x-www-form-urlencoded" -H "Accept: application/json" --data "code=sYChMYd9WlCxjmYaV60IW48W1vR69_g3KIcA8XIcuHGofzhVTtJbvfeik60ApbcfQvl8mVzm7J9wsltZ2hG_NA8ia2F2RQ4DFYuPF4j2Cbn5iRj0GpraskxGoWZ1xKKH&grant_type=authorization_code&redirect_uri=http://localhost:8000/index.html&client_id=Connectathon2020AllObservations"
(Added &client_id=Connectathon2020AllObservations)
Keith Carlson (Sep 11 2020 at 14:45):
Great! Thank you :)
Last updated: Apr 12 2022 at 19:14 UTC
