Stream: CARIN IG for Blue Button®
Topic: Connectathon - Onyx Health
Michele Mottini (Sep 10 2020 at 14:32):
@Michael Cox I see you listed under clients, but it seems that you have a server end point?
Amy Ballard (Sep 10 2020 at 15:44):
@Aaron Seib I've registered an account at http://con.safhir.io. It is "Pending Approval". Can I get approved so that I can test your sandbox?
Michele Mottini (Sep 10 2020 at 16:09):
Same for me ... I had an account from the last connectathon but did not work so I re-registered
Michele Mottini (Sep 10 2020 at 16:14):
...got approved..
Amy Ballard (Sep 10 2020 at 16:17):
Me too
Aaron Seib (Sep 10 2020 at 16:24):
Hi guys - thanks for registering. We did refresh the environment before today's Connectathon so unfortunately we are needing folks to re-register.
Josh Mandel (Sep 10 2020 at 16:26):
I'm trying to register for an account, but not receiving a verification code via email. Is there a known issue?
Josh Mandel (Sep 10 2020 at 16:30):
Got one finally (just took ~5min)
Josh Mandel (Sep 10 2020 at 16:31):
Now in "Your Account Registration is Pending Approval."
Michele Mottini (Sep 10 2020 at 17:05):
OK, app got approved, now trying to get the capability statement but GET https://nw-sf-con-uses0-rbyh-safhirapim.azure-api.net/CarinBB2.0/api/metadata
fail with 404 - is that the right end point?
Michele Mottini (Sep 10 2020 at 17:07):
...the authorization URL seems not to be working as well: GET https://nwsfconrbyhtenantb2c.b2clogin.com/nwsfconrbyhtenantb2c.onmicrosoft.com/oauth2/v2.0/authorize
gives a 404
Michael Cox (Sep 10 2020 at 17:21):
Michele Mottini said:
Michael Cox I see you listed under clients, but it seems that you have a server end point?
I apologize, that was entered in error, should be resolved under Aaron Seib now.
Michael Cox (Sep 10 2020 at 17:23):
Michele Mottini said:
OK, app got approved, now trying to get the capability statement but
GET https://nw-sf-con-uses0-rbyh-safhirapim.azure-api.net/CarinBB2.0/api/metadata
fail with 404 - is that the right end point?
Hi Michele,
It is at the base route without "/CarinBB2.0/api" - just https://nw-sf-con-uses0-rbyh-safhirapim.azure-api.net/metadata
I can add the CS at the route you first tried as well just to avoid further confusion.
Michele Mottini (Sep 10 2020 at 17:26):
OK thanks. Yes, that's the route your portal gives, so I'd say it should have a capability statement
Michele Mottini (Sep 10 2020 at 17:30):
ah, the authorization URL requires a parameter to work &p=b2c_1a_nw_vmi_signup_signin
- don't think we support that
Michael Cox (Sep 10 2020 at 17:56):
Michele Mottini said:
ah, the authorization URL requires a parameter to work
&p=b2c_1a_nw_vmi_signup_signin
- don't think we support that
Hi @Michele Mottini
Apologies about that formatting, thats a default way but it can be modified to put be put in the path if you are unable to support params.
Please use the following:
https://nwsfconrbyhtenantb2c.b2clogin.com/nwsfconrbyhtenantb2c.onmicrosoft.com/b2c_1a_nw_vmi_signup_signin/oauth2/v2.0/authorize
Michele Mottini (Sep 10 2020 at 18:01):
Thanks - those work. Probably it would be a good idea to return those in the capability statement
Michele Mottini (Sep 10 2020 at 18:03):
Now how do I get the patient ID ? launch/patient
does not work, the Patient resource does not support search and even trying to access directly a Patient using one of the id you emailed me does not work (either 404 or 403 depending on which end point I use)
Michele Mottini (Sep 10 2020 at 18:04):
(Also: https://nwsfconrbyhtenantb2c.onmicrosoft.com/nw-sf-con-uses0-rbyh-safhirapi-app/CarinBB2.0
is not a valid SMART scope)
Michele Mottini (Sep 10 2020 at 18:06):
Sorry, correction: GET https://nw-sf-con-uses0-rbyh-safhirapim.azure-api.net/Patient/abed0bd0-b956-4d74-92ed-4d68c60dd760
fails with 404
Michele Mottini (Sep 10 2020 at 18:06):
and GET https://nw-sf-con-uses0-rbyh-safhirapim.azure-api.net/CarinBB2.0/api/Patient/abed0bd0-b956-4d74-92ed-4d68c60dd760
fails with 401 (even if I am passing the token I got back) and a strange "Invalid identifier"
response body
Michele Mottini (Sep 10 2020 at 18:08):
abed0bd0-b956-4d74-92ed-4d68c60dd760
is (I believe) the patient id for user rby1810001 - that is the one I used to login
Michael Cox (Sep 10 2020 at 18:14):
Michele Mottini said:
and
GET https://nw-sf-con-uses0-rbyh-safhirapim.azure-api.net/CarinBB2.0/api/Patient/abed0bd0-b956-4d74-92ed-4d68c60dd760
fails with 401 (even if I am passing the token I got back) and a strange"Invalid identifier"
response body
That is not the patient's FHIR id for the user you logged in as (1810001) - I am curious where you got that guid?
send: GET base-url/CarinBB2.0/api/Patient - you will be returned only "yourself" and your patient id is there
Michele Mottini (Sep 10 2020 at 18:16):
From the email Aaron sent me - but that's the member id that is different from the patient id I guess
Josh Mandel (Sep 10 2020 at 18:21):
When I try to register an app at https://con.safhir.io/AppRequest/Edit, clicking the button has no effect. I don't see any errors on the console. Any ideas @Michael Cox ?
Michele Mottini (Sep 10 2020 at 18:22):
GET base-url/CarinBB2.0/api/Patient - you will be returned only "yourself" and your patient id is there
Mhh... this is not what the standard says - you should return the patient ID in the token response (if the client requested launch/patient
). Note also that there are cases when the patient is NOT yourself - because I could be getting the data of a dependent
Michele Mottini (Sep 10 2020 at 18:22):
Also:
1) Having to add extra things as CarinBB2.0/api
to the base URL is non-standard - no client would know to do that
2) That is a Patient search - and your capability statement say it is not supported
3) Being a search it should return a bundle and not a single resource
Josh Mandel (Sep 10 2020 at 18:22):
It's a very important point that @Michele Mottini is making -- the GET base-url/CarinBB2.0/api/Patient
behavior is not compatible with the SMART App Launch spec (or, for several reasons, with the FHIR base spec -- but even if you fixed those 1-3 which Michele noted, it'd still be incompatible with SMART).
Michael Cox (Sep 10 2020 at 18:28):
Josh Mandel said:
When I try to register an app at https://con.safhir.io/AppRequest/Edit, clicking the button has no effect. I don't see any errors on the console. Any ideas Michael Cox ?
Please use "https" for the protocol on your callback url. Is that a breaking change?
Michele Mottini (Sep 10 2020 at 18:30):
Another thing: the CapabilityStatement is returned with a Content-Type of application/fhir+json,charset=utf-8
(with a comma) - that is not valid, should be application/fhir+json; charset=utf-8
Michele Mottini (Sep 10 2020 at 18:31):
(Patient has the correct content type)
Josh Mandel (Sep 10 2020 at 18:53):
I can't use https for a localhost URL, and the instructions specifically say that http://localhost
should work.
Michele Mottini (Sep 10 2020 at 19:32):
@Michael Cox if you can fix the CapabilityStatement content type and have both /metadata and resources working off the same base URL I can work around the lack of launch/patient - but otherwise I am stuck
Michael Cox (Sep 10 2020 at 19:41):
Michele Mottini said:
Michael Cox if you can fix the CapabilityStatement content type and have both /metadata and resources working off the same base URL I can work around the lack of launch/patient - but otherwise I am stuck
I have re-upped the capability statements at the Base URLs given to you, and I believe the headers should be coming back correctly. Can you take a look at this now?
https://nw-sf-con-uses0-rbyh-safhirapim.azure-api.net/CarinBB2.0/api/metadata
https://nw-sf-con-uses0-dmdh-safhirapim.azure-api.net/CarinBB2.0/api/metadata
Michele Mottini (Sep 10 2020 at 19:42):
Thanks - trying now
Michele Mottini (Sep 10 2020 at 19:46):
OK - I was able to connect now.
Now GET https://nw-sf-con-uses0-rbyh-safhirapim.azure-api.net/CarinBB2.0/api/ExplanationOfBenefit?patient=6fbfa3ba-85e2-45fc-8268-beccdf0cc2f3
fails with "Invalid Patient reference format '6fbfa3ba-85e2-45fc-8268-beccdf0cc2f3'"
Michele Mottini (Sep 10 2020 at 19:47):
It expects &patient=Patient/[id]
?
Michele Mottini (Sep 10 2020 at 20:33):
OK, changing the patient references like that we can get the data - here are are condition extracted from those claims as displayed in our app:
image.png
Michele Mottini (Sep 10 2020 at 20:39):
ExplanationOfBenefit/b580dbe4-cd2a-497c-9934-9c8d67d4acc5 has an item
without a productOrService
element
Michele Mottini (Sep 10 2020 at 20:41):
ExplanationOfBenefit.type should use codes from http://hl7.org/fhir/us/carin/CodeSystem/carin-bb-claim-type
, not http://terminology.hl7.org/CodeSystem/claim-type
Richard Braman (Sep 10 2020 at 21:37):
@Josh Mandel , we think the bug you were experiencing was due to the submit button not being re-enabled when a form validation error occurred. we are fixing it as we speak. You should be able to put in http://localhost if you refresh the page and re-enter the data. Please excuse the inconvenience.
Josh Mandel (Sep 11 2020 at 16:23):
OK -- I've registered a client now, thanks! Some issues:
- It looks like I somehow registered a confidential client when what I need is a public client. Is there a way to switch, or to request a public client in the first place?
- In my client overview I see: "Scope: https://nwsfconrbyhtenantb2c.onmicrosoft.com/nw-sf-con-uses0-rbyh-safhirapi-app/CarinBB2.0" -- this is not a standardized scope. Will my client be able to request scopes like "patient/Coverage.read", and if so could this be included in the overview pane?
- I'm a bit confused about the model when it comes to safhir instances and health systems -- I registered my client for "Diamond health" and "Ruby health" but have only one "baseUrl" of "https://nw-sf-con-uses0-rbyh-safhirapim.azure-api.net/CarinBB2.0/api" -- does this one endpoint get me data about people in both health systems? Is there an overlapping namespace, or are they partitioned somehow?
- I don't see a SMART configuration file at https://nw-sf-con-uses0-rbyh-safhirapim.azure-api.net/CarinBB2.0/api/.well-known/smart-configuration
Michele Mottini (Sep 11 2020 at 16:24):
You have to use that non-standard scope, I tried patient/*.read
and it was rejected
Josh Mandel (Sep 11 2020 at 16:25):
- the "copy top clipboard" copies not only data, but a bunch of whitespace to either side, e.g. my client ID copies as (quotes added to clarify start/end):
"
12a1658e-ef80-42db-96e7-eff78a9662c0
"
Josh Mandel (Sep 11 2020 at 16:28):
- I can't add a redirect URI to my client -- box is greyed out
- Formatting of the redirect URI box for my registered client has a
,
in it, even though the description above the box (and the originally submitted formatting) does not
image.png
Josh Mandel (Sep 11 2020 at 16:30):
- Approved apps list is showing me two rows for one app:
image.png
Josh Mandel (Sep 11 2020 at 16:30):
- I just submitted a new registration to work around the redirect_uri limitation; would be great if someone can approve it ASAP
Michele Mottini (Sep 11 2020 at 17:01):
I think the idea is that you register one app and then one or more health plan for that app - and you get separate client id / client secret for each of those health plan you want to connect to, that's why the display is like that
Josh Mandel (Sep 11 2020 at 17:07):
Interesting. And it's just buggy by not showing my "Diamond health" anywhere, and not showing my the name in one row?
Michele Mottini (Sep 11 2020 at 17:09):
I think you got approved for one but not the other yet
Michele Mottini (Sep 11 2020 at 17:10):
but maybe is better if people from Onyx answer instead of me speculating!
Josh Mandel (Sep 11 2020 at 17:14):
That would be great! @Richard Braman when you have eyes here...
Josh Mandel (Sep 11 2020 at 17:21):
Looks like my first app was approved but my second was rejected?
This makes testing harder ;-)
(Note, the rejection screenshot above shows a blank entry for a name, but my app did have a name...)
Richard Braman (Sep 11 2020 at 19:56):
@Josh Mandel SAFHIR admins rejected you because you were using an invalid email address I think. Can you try again with your email address.
Aaron Seib (Sep 11 2020 at 20:09):
@Michele Mottini and @Josh Mandel - Hi guys thanks for this testing and feedback - I'd love to set up a time to follow up. I'd love to spend some time sussing out on what you've encountered and verify we have corrected them in the environment or sort it out otherwise.
Michele Mottini (Sep 11 2020 at 20:11):
Sure, I am around. From the point of view of the server implementation the main thing that trip our client is the lack of launch/patient
, second is use non-standard access scope - so pretty simple
Aaron Seib (Sep 11 2020 at 20:23):
@Michele Mottini - your the greatest - I'd really like to talk with you and @Josh Mandel about the launch/patient scope in the context of this IG to make sure we are all on the same page. It may need some additional discussion as I have heard some different feedback from different folks.
Michele Mottini (Sep 11 2020 at 20:39):
It is super-easy: 'When the client requests launch/patient
the server has to return the FHIR patient ID in the patient
field of the token response'
Aaron Seib (Sep 11 2020 at 21:19):
Yep - your correct my friend. Let me coordinate with my folks and get it updated in the Connectathon environment and we can schedule some time with you and Josh to keep pounding on it. This is all part of the value of participating in Connectathon!!!
Last updated: Apr 12 2022 at 19:14 UTC