FHIR Chat · Connectathon - Onyx Health · CARIN IG for Blue Button®

Stream: CARIN IG for Blue Button®

Topic: Connectathon - Onyx Health


view this post on Zulip 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?

view this post on Zulip 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?

view this post on Zulip 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

view this post on Zulip Michele Mottini (Sep 10 2020 at 16:14):

...got approved..

view this post on Zulip Amy Ballard (Sep 10 2020 at 16:17):

Me too

view this post on Zulip 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.

view this post on Zulip 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?

view this post on Zulip Josh Mandel (Sep 10 2020 at 16:30):

Got one finally (just took ~5min)

view this post on Zulip Josh Mandel (Sep 10 2020 at 16:31):

Now in "Your Account Registration is Pending Approval."

view this post on Zulip 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?

view this post on Zulip 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

view this post on Zulip 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.

view this post on Zulip 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.

view this post on Zulip 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

view this post on Zulip 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

view this post on Zulip 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

https://nwsfconrbyhtenantb2c.b2clogin.com/nwsfconrbyhtenantb2c.onmicrosoft.com/b2c_1a_nw_vmi_signup_signin/oauth2/v2.0/token

view this post on Zulip 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

view this post on Zulip 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)

view this post on Zulip 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)

view this post on Zulip 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

view this post on Zulip 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

view this post on Zulip 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

view this post on Zulip 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

view this post on Zulip 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

view this post on Zulip 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 ?

image.png

view this post on Zulip 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

view this post on Zulip 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

view this post on Zulip 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).

view this post on Zulip 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 ?

image.png

Please use "https" for the protocol on your callback url. Is that a breaking change?

view this post on Zulip 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

view this post on Zulip Michele Mottini (Sep 10 2020 at 18:31):

(Patient has the correct content type)

view this post on Zulip 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.

view this post on Zulip 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

view this post on Zulip 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

view this post on Zulip Michele Mottini (Sep 10 2020 at 19:42):

Thanks - trying now

view this post on Zulip 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'"

view this post on Zulip Michele Mottini (Sep 10 2020 at 19:47):

It expects &patient=Patient/[id] ?

view this post on Zulip 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

view this post on Zulip Michele Mottini (Sep 10 2020 at 20:39):

ExplanationOfBenefit/b580dbe4-cd2a-497c-9934-9c8d67d4acc5 has an item without a productOrService element

view this post on Zulip 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

view this post on Zulip 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.

view this post on Zulip Josh Mandel (Sep 11 2020 at 16:23):

OK -- I've registered a client now, thanks! Some issues:

view this post on Zulip Michele Mottini (Sep 11 2020 at 16:24):

You have to use that non-standard scope, I tried patient/*.read and it was rejected

view this post on Zulip 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
            "

view this post on Zulip 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

view this post on Zulip Josh Mandel (Sep 11 2020 at 16:30):

  • Approved apps list is showing me two rows for one app:
    image.png

view this post on Zulip 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

view this post on Zulip 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

view this post on Zulip 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?

view this post on Zulip Michele Mottini (Sep 11 2020 at 17:09):

I think you got approved for one but not the other yet

view this post on Zulip Michele Mottini (Sep 11 2020 at 17:10):

but maybe is better if people from Onyx answer instead of me speculating!

view this post on Zulip Josh Mandel (Sep 11 2020 at 17:14):

That would be great! @Richard Braman when you have eyes here...

view this post on Zulip Josh Mandel (Sep 11 2020 at 17:21):

Looks like my first app was approved but my second was rejected?

image.png

This makes testing harder ;-)

(Note, the rejection screenshot above shows a blank entry for a name, but my app did have a name...)

view this post on Zulip 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.

view this post on Zulip 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.

view this post on Zulip 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

view this post on Zulip 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.

view this post on Zulip 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'

view this post on Zulip 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