search

oktadev / okta-smartfhir-docs

Documentation for using Okta as a SMART/FHIR authorization server.
MIT License
20 stars 9 forks source link

fhirUser and FHIR Resource format #9

Open wmagda opened 3 years ago

wmagda commented 3 years ago

I'm trying to get this authz server working with https://github.com/awslabs/fhir-works-on-aws-deployment/tree/smart-mainline The problem I'm running into right now is the format of fhirUser and other claims. I believe that according to the FHIR spec fhirUser and FHIR resource claims are supposed to be in the URL format. Exmaple: "fhirUser": "https://fhir-ehr-code.cerner.com/r4/ec2458f2-1e24-41c8-b71b-0e701af7583d/Practitioner/12742069" or

And this is what FHIR AWS Works is checking: exports.FHIR_USERREGEX = /^(?(http|https):\/\/([A-Za-z0-9-\.:%$/])+)\/(?Person|Practitioner|RelatedPerson|Patient)\/(?[A-Za-z0-9-.]+)$/; exports.FHIR_RESOURCEREGEX = /^((?(http|https):\/\/([A-Za-z0-9-\.:%$/])+)\/)?(?[A-Z][a-zA-Z]+)\/(?[A-Za-z0-9-.]+)$/;

This authz server implementation (following the setup guidelines) is generating claims like this: launch_response_patient: 'c769110f-4d4e-4375-a706-c5d78f729544' fhirUser: 'Patient/1440422'

This is resulting in token getting rejected due to: Requester's identity is in the incorrect format Resource is in the incorrect format

Could somebody help me reconcile the difference here?

Thanks!

dancinnamon-okta commented 3 years ago

Hey- apologies for the delay here. I think this is mostly due to how I have the example set up.
If you take a look at the mock_patient_service, this is where the IDs are provided for the example. The intent of course is for this data to come from an API of some sort instead of being hard-coded in a JSON file. https://github.com/oktadev/okta-smartfhir-demo/blob/master/lib/mock_patient_service.js

Same goes for the fhirID of a given user in the Okta directory- the actual ID is from the HAPI data in my example- so you can update that value with one that is valid for the AWS implementation. The reference implementation isn't manipulating the values, so you should be able to put them in the format you need right within that mock JSON, or within the user's profile in Okta. I'll take a look at making the example more realistic by putting the values in full URL format though!