Provide a way to select which access token to use for the API test kits

[cooperthompson]

In the Single Patient API test sequence, the access token is automatically defaulted in, and it isn't editable. However, it isn't clear which access token is being used. If you run the test kit in order, there are three access tokens floating around:

1. The token from the Standalone Patient App sequence
2. The token from the Limited Access App sequence
3. The token from the EHR Practitioner App sequence

I've haven't really figured out exactly which one gets used, and if it depends on what order the tests were run. But I think it would be nice if you just gave the user a drop-down list with the list of tokens, and which preceding sequence was used to acquire the token .

[nathanloyer]

I found inferno 1 always used the last token acquired, so if you run the steps in order it will always be the one from the EHR launch. It is in fact their intent that we only run the single patient api tests for certification with the EHR launch token. You can run the standalone launch and then the single patient tests if you want, but you don't have to. The limited access token would be expected to fail many tests because it only gives you access to some of the resources.

[nathanloyer]

I do agree that this could be made more clear in the UI.

[Jammjammjamm]

The single patient api tests still use the most recent token acquired.

[cooperthompson]

We also found that Inferno 1.9 always used the last token. We always re-ran the patient launch step before doing the API tests so we would make sure the API content being validated was using the patient token not the EHR launch token.

I'm curious about how firm that intent was. Historically, API certification criteria have been more patient-oriented, and we (Epic) were carrying that intent forward.

I suppose the "robust" solution is to run the API tests against both provider-facing and patient-facing tokens. Our APIs should pass both, but we always put the patient-facing APIs front and center out of habit.

[Jammjammjamm]

It was an intentional decision to default to using the EHR launch token if you just run through the tests in order. We weren't comfortable saying that all of the data we need to see has to be present in a single patient's record. As a result, we provided a way to specify multiple patient ids and check that those patients together have all of the necessary data. The potential need to access multiple patients' data meant that it made sense to default to using the credentials from the user-scoped EHR launch.

As you say, running the single patient API tests using both sets of credentials would be more robust. There are several cases where we could test more thoroughly (e.g. even more SMART launch variants), but we try to balance the potential benefits to interoperability, the testing experience, and the development/maintenance effort. In this specific case, I'd consider the potential interoperability benefits and development/maintenance effort pretty low, but the negative impact to the testing experience quite high.

[nathanloyer]

We weren't comfortable saying that all of the data we need to see has to be present in a single patient's record.

That makes a lot of sense to me since some of the profiles are specific to children and then a lot of other data elements you are validating wouldn't make sense on a child patient. For running inferno to get the tests passing we have 5 patients we are using. I have run it a few times with the standalone patient launch, but a lot of tests are skipped due to missing data.

[cooperthompson]

Your reasoning makes sense to me as well.

However, I still think it would be nice to have an access token selector. Even if we don't need to test across all token types for certification, it would be useful for ad-hoc testing. This is clearly a quality of life enhancement that isn't required or necessary for certification. So I understand if you have other things to prioritize.