Stream: CARIN IG for Blue Button®
Topic: Connectathon - 1Up Health Server
Amy Ballard (Sep 10 2020 at 15:23):
@Kyle Brew I've registered a client app and am attempting to login. The authorize redirect seems ok, but neither username/password from https://1up.health/dev/doc/smart-on-fhir is working for me.
Michele Mottini (Sep 10 2020 at 16:05):
...same here
Liam O'Toole (Sep 10 2020 at 17:28):
Hey Amy and Michele, what error are you receiving when attempting to use either credential?
Michele Mottini (Sep 10 2020 at 17:43):
Invalid user name or password
Liam O'Toole (Sep 10 2020 at 18:15):
and you are hitting 'https://1up.health/auth/heart.com/authorize?response_type=code&aud=https://api.1up.health/fhir/r4&client_id={client_id}
&state=${state}&redirect_uri=${app_redirect_uri}' with updated redirect, client id and state? I just tried this out with a few different testing applications and both logins worked for me. If you share your application names with me I can look and see if I can figure out if something went wrong somewhere
Amy Ballard (Sep 10 2020 at 18:43):
@Liam O'Toole The authorize endpoint found at https://api.1up.health/fhir/r4/metadata is https://1up.health/auth/authorize
Liam O'Toole (Sep 10 2020 at 18:44):
@Amy Ballard yeah sorry for the confusion there, I will talk to the other engineers about fixing this. For now, I would follow the exact steps at https://1up.health/dev/doc/smart-on-fhir
Michele Mottini (Sep 10 2020 at 18:47):
Is the token URL different as well?
Liam O'Toole (Sep 10 2020 at 18:47):
nope! only the authorize url is different, everything else in the metadata endpoint should be accurate
Amy Ballard (Sep 10 2020 at 18:50):
Also when I drop the full authorize redirect into Chrome, I get the login page. When I try Safari, I am immediately redirected to the callback URL
Amy Ballard (Sep 10 2020 at 18:51):
However, the authorize redirect on my mobile (using Safari) does bring up the login
Michele Mottini (Sep 10 2020 at 18:54):
The token URL in the metadata is https://zwiuchaef2.execute-api.us-west-2.amazonaws.com/prod/oauth2/token, but that host name does not resolve
Liam O'Toole (Sep 10 2020 at 18:58):
ah okay, seems like the meta data endpoint is all messed up.. ill send a list of urls one second, sorry about that!
Liam O'Toole (Sep 10 2020 at 19:00):
token url: https://api.1up.health/fhir/oauth2/token
resource_url for r4: https://api.1up.health/fhir/r4
Liam O'Toole (Sep 10 2020 at 19:00):
@Amy Ballard interesting, thank you for pointing that out, I will do some testing with safari and see if I can recreate that issue
Michele Mottini (Sep 10 2020 at 19:10):
Getting a 503 BadGateway error from that token url
Amy Ballard (Sep 10 2020 at 19:10):
The new authorize redirect works in Safari, but displays a little funny on mobile.
Liam O'Toole (Sep 10 2020 at 19:44):
@Michele Mottini what are you posting in the body? it should look like this
curl -X POST 'https://api.1up.health/fhir/oauth2/token' \
-d "client_id=" \
-d "client_secret=" \
-d "code=" \
-d "grant_type=authorization_code"
Michele Mottini (Sep 10 2020 at 19:57):
You don't support client id and secret in the Authorization header ?
Michele Mottini (Sep 10 2020 at 20:00):
OK, that was it - switched to client id and secret in the post body and it worked....
Michele Mottini (Sep 10 2020 at 20:01):
except that we do not get back the patient id, this is the token response:
{
"refresh_token": "9cc80eea4bfe420e8264c23da0a1a71a",
"token_type": "bearer",
"access_token": "2e9a66ae6dc8466bbcbd11f2dd8e110c",
"expires_in": 7200,
"scope": "patient/*.read launch/patient offline_access"
}
Liam O'Toole (Sep 10 2020 at 20:19):
Not yet we are working on supporting it in the authorization header though... if you hit https://api.1up.health/fhir/r4/Patient with the bearer token authorization, you will get the list of patients returned and can extract the ids from there
Michele Mottini (Sep 10 2020 at 20:52):
Tying that but I cannot get the conformance: GET https://api.1up.health/fhir/r4/metadata fails with a 406:
{
"resourceType": "OperationOutcome",
"id": "bsoys13f9eb",
"issue": [
{
"severity": "error",
"code": "value",
"details": {
"text": "this accept header is not supported application/fhir+json;charset=utf-8"
}
}
]
}
Liam O'Toole (Sep 10 2020 at 21:09):
are you setting some headers? I just did a get to 'https://api.1up.health/fhir/r4/metadata' without any headers set and it worked fine.. I imagine there must be something being passed that the endpoint did not like
Michele Mottini (Sep 10 2020 at 21:10):
Yes, the client is setting the Accept header to application/fhir+json;charset=utf-8 - that is the standard FHIR one
Liam O'Toole (Sep 10 2020 at 21:12):
yup just talked to the lead api engineer, he found a bug with charset.. should work without it for now, a fix should be out shortly though
Liam O'Toole (Sep 10 2020 at 21:13):
the fix for the token url is out as well so once charset is fixed it should be good to go
Michele Mottini (Sep 10 2020 at 21:15):
OK, thanks, let me know when I can test again
Liam O'Toole (Sep 11 2020 at 13:32):
Hey @Michele Mottini it should be working now
Michele Mottini (Sep 11 2020 at 16:16):
@Liam O'Toole I can get the metadata, but no luck trying to get the patient - GET GET https://api.1up.health/fhir/r4/Patient fails with a 403:
{
"resourceType": "OperationOutcome",
"id": "29nwa07fydi",
"issue": [
{
"severity": "error",
"code": "value",
"details": {
"text": "scope provided does not have access to perform this operation"
}
}
]
}
Michele Mottini (Sep 11 2020 at 16:18):
tried to switch to user/*.read instead of patient/*.read but got same error
Liam O'Toole (Sep 11 2020 at 16:41):
huh, a scope of user/*.read should work fine... if theres only synthetic data under the user you could share the token and I could look into it more. Either way I will test a few things out to see if I can figure out what might be happening
Michele Mottini (Sep 11 2020 at 16:44):
The token is 2365f55f1d8c48a08109b108d3c9f04e
Liam O'Toole (Sep 11 2020 at 17:02):
looking into a bug with how we are enforcing read only access... could you try with user/*.* to see if it works? Will hopefully have a fix to *.read soon
Michele Mottini (Sep 11 2020 at 17:04):
Yes, that worked
Michele Mottini (Sep 11 2020 at 17:05):
Got no data back though
Michele Mottini (Sep 11 2020 at 17:05):
GET https://api.1up.health/fhir/r4/ExplanationOfBenefit?patient=24514bbe8198 returned
{
"resourceType": "Bundle",
"type": "searchset",
"total": 0,
"entry": []
}
Liam O'Toole (Sep 11 2020 at 17:27):
I am not sure why that is happening either (you are becoming our bug finder lol).. If you just hit the endpoint without patient=id you should get the EOB's back.. also looking into why the query string isn't working
Michele Mottini (Sep 11 2020 at 17:29):
My client cannot not pass a patient ID...
Liam O'Toole (Sep 11 2020 at 17:49):
can you try again? It seems to be fixed in my testing
Michele Mottini (Sep 11 2020 at 18:12):
No, same thing
Liam O'Toole (Sep 11 2020 at 18:40):
hm, requests with either patient= and patient-reference= are working for me... Ill keep trying to recreate your problem though
Paul Bastide (Sep 11 2020 at 18:45):
out of curiosity where does the patient-reference parameter come from?
Michele Mottini (Sep 11 2020 at 18:53):
If it helps the request is: x-amzn-requestid : a3dc5730-c0ef-4699-8a82-a2ff297dd796
Pat Taylor (Sep 15 2020 at 21:49):
@Rob Hausam @Amol Vyas @Mark Roberts Hi Rob, I’ve been working on the terminologies on the CARIN for BB IG. Happy to chat with you.
Rob Hausam (Sep 16 2020 at 12:10):
@Pat Taylor Hi, Pat. It was good to have you and Lenel on the UTG call yesterday. And I'm happy to look for a time to chat with you (and anyone).
Pat Taylor (Sep 21 2020 at 14:19):
@Rob Hausam @Lenel James Hi Rob, sounds good. Adding Lenel.
Rob Hausam (Sep 21 2020 at 23:53):
Do we have slot(s) to look at this during the rest of the week?
Last updated: Apr 12 2022 at 19:14 UTC
