Stream: implementers
Topic: VA Lighthouse
Jason Walonoski (Jun 19 2018 at 19:00):
http://portal.lighthouse.vaftl.us
Grahame Grieve (Jun 19 2018 at 19:48):
I do not see where the smart end points are documented, nor can I get the conformance statement to find out what they are...
Michele Mottini (Jun 19 2018 at 20:43):
...I asked for details using their form...
Grahame Grieve (Jun 20 2018 at 01:16):
apparently they have not published a conformance statement... but there's no SMART end point information available anywhere else either
Andy Stein (Jun 20 2018 at 17:21):
Grahame, sorry for the delay. I was talking to some coworkers to make sure I understood the request clearly.
Our portal in the sandbox is using the following authorize and token endpoint. Actually we are just using authorize currently with an implicit grant.
https://va.oktapreview.com/oauth2/ausf3a1z7uI5V3xjU0h7/v1/authorize
https://va.oktapreview.com/oauth2/ausf3a1z7uI5V3xjU0h7/v1/token
The integration with Okta is a bit of a work in progress. If you select the Register with Okta link available from the portal (select Okta Authentication button) you will create an account and be automatically added to trusted developers group. That will allow you to get tokens from within the portal app.
When you register for an Okta account you also provide the app type and your app redirect for the application you are developing. I will need to work more with Okta on how a developer can register their app and get their own assigned client Id for direct calls from their own app.
Does this help? If you have more questions, can we get together and discuss Thursday morning with some of my coworkers?
Andy
Andy Stein (Jun 20 2018 at 18:35):
I also have someone adding the conformance statement to our API in the sandbox. It is in our production deployment but was left out by accIdent in the sandbox during our move to deploy to AWS.
Michele Mottini (Jun 20 2018 at 18:47):
What would be helpful (needed?) is implementing SMART - so that clients can figure out the OAuth end points from the FHIR conformance, and they can get the patient ID
Michele Mottini (Jun 20 2018 at 18:48):
and yes, something is needed to register the apps (and maintain those registrations)
Michele Mottini (Jun 20 2018 at 18:52):
..and SMART = code grant, not implicit
Michele Mottini (Jun 20 2018 at 19:11):
(SMART specs are at http://docs.smarthealthit.org/authorization/)
Grahame Grieve (Jun 20 2018 at 20:53):
thanks Andy. The the 2 end-points are what I was looking for, but I also need a client id
Andy Stein (Jun 20 2018 at 21:03):
This is the call the portal makes (all scopes specified) so it has the portal client id; but when you execute outside the portal I'm getting a Page Not Found on the redirect; I'm checking on that. I also have an email out to Okta asking about the ability of developers to register their own app and get their own client id after they have created an Okta account. That might be the best approach. I'll update here when I hear back from them.
Andy Stein (Jun 21 2018 at 11:21):
I wanted to remind everyone and encourage them to visit the VA API Developer Sandbox (http://portal.lighthouse.vaftl.us) and to register with both the portal and Okta via the Okta Authentication button (via the portal). While the portal will be available beyond this week, the ability to register as an Okta trusted developer so you can request access tokens for use with the API calls to ~7000 synthetic veterans (and growing) may only be open to all this week. Once you are a registered with Okta, you will be able to request tokens beyond this week. Visit the Getting Started page on the portal for more details. I will be upstairs on the mezzanine from 10-11 today to answer any questions. If you can't find me, you can reach me at 321-272-9516.
Andy Stein (Jun 22 2018 at 00:30):
@Grahame Grieve @Michele Mottini @Dave Carlson The conformance statement has been added to the API in the sandbox (https://lighthouse.vaftl.us/metadata). I'm verifying with Okta on the client id for each developer and also checking to see if they are supporting more than just implicit grant currently. If not, we will need to change that as well. I will update here as I get those answers.
Michele Mottini (Jun 22 2018 at 02:42):
Thanks Andy. Conformance looks good
Andy Stein (Jun 22 2018 at 11:48):
@Grahame Grieve @Michele Mottini @Dave Carlson: To get your Okta client id/secret go to https://va.oktapreview.com and login. Then hit "Admin" at upper right. Then "My Applications" link at the top right of the next page. Then select "Manage Your App". Select the hyperlink for your app (should be "DEV - <email> -<client id>"). After that you can go to the "General" tab and you should be able to set up grant types, re-direct, and view client secret. Let me know if that works OK for you.
Michele Mottini (Jun 22 2018 at 13:51):
Tried with out test Web app (https://demo.careevolution.com/SMARTest/SMARTest.html) and it does not work because the token end point does not support CORS
Michele Mottini (Jun 22 2018 at 13:51):
(Browser console error message: Failed to load https://va.oktapreview.com/oauth2/ausf3a1z7uI5V3xjU0h7/v1/token: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://demo.careevolution.com' is therefore not allowed access.)
Michele Mottini (Jun 22 2018 at 14:26):
Tried with our production app - that has a server and so does not require CORS: I was able to complete the authentication sequence, but there is no support for the launch/patient scope and no patient ID is returned in the token response....how can an app figure out the FHIR patient ID?
Michele Mottini (Jun 22 2018 at 14:28):
Some things about Okta:
Michele Mottini (Jun 22 2018 at 14:28):
1) It requires two factor authentication and it offers you to save it for no longer than 30 minutes - that is a bit drastic (I think the 'standard' is more like 30 days)
Michele Mottini (Jun 22 2018 at 14:29):
2) Eventually there should be a way to create and manage more than one app
Michele Mottini (Jun 22 2018 at 14:30):
3) There should be some test logins corresponding to test patients to use for apps - now I am logging in with my own identity but it would not match any of you test patient data (maybe they already exist but I could not find them)
Andy Stein (Jun 22 2018 at 14:36):
We are working with Okta to embed the patient ICN in the token (and support the launch /patient scope); since we are currently supporting a patient getting his/her own records, we will need Okta to use an API to MVI (Master Veteran's Index) to return a veteran's patient ICN and then they can store that in their universal directory and include in future tokens . In the sandbox right now we are not yet matching the patient ICN from the token to the ICN requested in the API call. So you can read /search any of the 7000 current patients (some provided in the GettingStarted page). But what you are talking about will be coming So, agree with your #3 above that we need some test patients (with published login credentials) so that we can pre-populate with the synthetic data patient id so the token id would match.
Andy Stein (Jun 22 2018 at 14:38):
I appreciate you checking this out and your feedback!
Michele Mottini (Jun 22 2018 at 14:48):
OK, great, thanks Andy
Michele Mottini (Jun 22 2018 at 14:49):
Our app expects the patient ID, so I am sort of stuck testing, but maybe I can patch it to use a hard-coded patient ID to try to import some data
Michele Mottini (Jun 22 2018 at 15:38):
I hard-coded one of the test patient ID and I was able to import data (medications and conditions) without problems
Michele Mottini (Jun 22 2018 at 15:38):
Two things I noticed:
Michele Mottini (Jun 22 2018 at 15:39):
1) Various resources references Encounter, but the Encounter resource is not supported, so those references cannot be resolved
Michele Mottini (Jun 22 2018 at 15:42):
2) Searches with _count greater than 20 fail - I think most server just ignore _count values that are out of valid range, defaulting to the closest valid range
Andy Stein (Jun 22 2018 at 15:48):
Thanks for that. I expect the Encounter issue as the DB tables have been loaded for 7 resources thus far. More coming. I’ll talk to the team on the _count comment. You can get to all the data by using value 20 or less and then specifying the desired page, correct?
Lloyd McKenzie (Jun 22 2018 at 16:41):
FHIR doesn't support specifying a desired page - you just navigate the "next" link until you get to where you want to be.
Michele Mottini (Jun 22 2018 at 17:44):
Yes, I can get all the data following the next links - works fine
Andy Stein (Jun 26 2018 at 11:56):
I updated the "Getting Started" page on the portal with the steps to access the assigned client id and secret from Okta for your application as well as how to access the grant type configuration. With this you should be able to integrate the API into your application (as Michele has done).
We will be changing the API behavior (in production and sandbox) to have the behavior that Michele mentioned in regard to bundles, i.e. don't return an error if _count exceeds the server maximum, but instead use the max _count for the server.
Still need to get with Okta on the launch/patient scope and including the patient id in the delivered tokens. Also, need to check if we can create a few test patient accounts and publish credentials so developers and use that to simulate a patient logging into the application authorizing access to his/her own information.
Michele Mottini (Jun 26 2018 at 12:42):
Thanks Andy
Chris Geiersbach (Jul 13 2018 at 00:48):
Hi @Andy Stein
Chris from Verily - my other question regarding OAuth was whether there are plans to support the "patient/*.read" scope?
Thanks! Looking forward to when Okta supports the patient ID in the token, for now we'll hardcode a patient ID too for testing.
Andy Stein (Jul 13 2018 at 00:52):
@Chris Geiersbach Yes, wildcard scopes was on our to-do list for Okta. Okta is under a separate agreement with the VA (via FTC) so we are presenting them our wish list, but launch/patient, wildcard read, and patient id embedded in the token are all on our list. We have provided them our needs for supporting SMART on FHIR and they are reviewing. We are supposed to get together with them again next week to review.
Andy Stein (Jul 20 2018 at 16:05):
@Chris Geiersbach update for you. Okta has added support for the "patient/*.read". We have not put that on our portal yet, but if you are integrating directly from your SMART App, it's there now. Okta also supports offline_access scope and refresh tokens in the OAuth flow. They are adding support for launch/patient and embedding the patient id in the token. For that, we will add the ability in the portal allowing the developer to set a patient id for his/her own Okta account to that of a synthetic patient in the database. I will publish lists of good synthetic patients for the various resources as well as diseases/ailments (e.g.. diabetes or lung cancer).
Last updated: Apr 12 2022 at 19:14 UTC
