Patient and EHR launch flows should be separated

[daliboz]

Thank you for reporting a possible bug in Inferno! Please fill in as much of the template below as you can.

Subject of the issue
I cannot test our patient and practitioner launch flows. The current suite assumes that the same application can be used for both sets, and that the same FHIR URL is involved, and there's not a good way to bypass the assumptions/previous test suites or mark them as NA.

When I try to skip the patient tests (let them fail), I get to the "EHR Practitioner App" and it sits at the "waiting for launch" page forever/never makes progress. If this needs to test an actual EHR launch, the suite itself will need to act as if it's the EHR (I assume it's not going to launch an external chart). It would need an input for a launch scope to provide the app, and it would use the provided FHIR URL as the iss.

Your environment

• Edition of inferno (Community or Program): Program, DSTU 2
• Version of inferno: 2.7.0 (public website)
• Which browser and version(s) is the bug present on?: I'm using Chrome, 78.0.3904.97

Steps to reproduce

1. Select the DSTU 2 Program
2. Enter this FHIR URL: https://fhir-ehr.sandboxcerner.com/dstu2/0b8a0111-e8e6-4c26-a91c-5069cbc6b1ca/
3. Click "Begin"
4. On next page, click "Run tests" Use client id d545b3a7-c82a-4315-8810-2ea6b9efaf3b (public client). (You'll see errors about the well known endpoint, which is expected right now)
5. Click Next.
6. On patient tests, use defaults (this won't work, so you can cancel out).
7. Click Next.
8. On EHR Tests, enter following (note: using "user" level scopes since I can't mimic an EHR launch without being able to provide a launch code)
   Scopes: user/AllergyIntolerance.read user/Binary.read user/CarePlan.read user/Condition.read user/Device.read user/DocumentReference.read user/Encounter.read user/Goal.read user/Immunization.read user/MedicationStatement.read user/Observation.read user/Patient.read user/ProcedureRequest.read user/RelatedPerson.read user/Person.read user/Practitioner.read profile openid online_access
9. Click "Execute"

The test will just sit there waiting for a redirect. If you click cancel, there will be no progress nor error shown on the main page to indicate what went wrong.

Expected behavior
Ideally, I would be able to run separate suites/steps for practitioner and patient apps, since they are never the same app for both workflows and require different permissions in real systems. If the app intends to test an EHR launch for practitioner, it will need to allow entry of a launch code to provide during authentication. Then the application would launch and follow normal redirects, or display an error if it encounters one.

Actual behavior
Just sits at the "waiting for redirect" window and you have to cancel out. No steps are completed, no additional output is provided.

[daliboz]

I'm trying to dig through our logs to determine if something failed during auth, but I would hope to see that in an error on the inferno website/the app should handle that

[Jammjammjamm]

The EHR under test has to perform the launch in the EHR launch test because the ability to launch a SMART app from within an EHR is one of the capabilities being tested.

You are correct about needing different configuration for patient/practitioner apps, and I will create a ticket address that.

[daliboz]

When I do the launch from my system, the error I see in Inferno states that the initial redirect back to the OAuth endpoint (which I didn't see) is missing the launch code parameter.

Edit: it looks like the application is not encoding the spaces in the scopes using %20 - instead it is using the + sign. Would you like me to log this as a separate issue?

[Jammjammjamm]

After Inferno shows the waiting for launch modal and you perform a launch, you should a modal like this which allows you to inspect the url you are being redirected to, including the launch parameter:

If you click on the "HTTP Requests" tab, you can see the launch url that was received and check the original launch value received:

I'm not sure that encoding spaces as + in query parameters is incorrect, but that is something we would want to track separately.

[daliboz]

Ok, thanks! That helped. It looks like the configuration behind the scenes was missing an important scope - I was able to get it to launch