Using multiple SMART on FHIR access points in power chart.

[Gus Agudelo]

Is it acceptable for a single app to service both the access point in the TOC of the patient chart and within a toolbar button of the Organizer view. 

Here is what I am seeing within the sandbox environment: 

Within the TOC of the patient chart whenever a new patient is opened and the app is accessed, the SMART routines are called where a code is delivered to the app and the app uses the code to authenticate back to Millenium and receive the context of the practitioner and the patient. This works great.

However, once the access point in the Organizer View toolbar is access, the call to the app works fine, however thereafter every time a new patient is opened and the app is accessed through that patients TOC, the patient context seems to always be one behind. 

For instance when working normally and correctly: open Patient A, receive context for patient A (in the app), open patient B receive context for patient B, open patient C receive context for patient C.

After opening the Organizer View access-point, it begins to work abnormally. Open the Organizer View Access Point there is no patient context (as expected), open Patient A there is still no patient context, open Patient B receive context for Patient A, open Patient C receive context for patient B, etc...

I'm fairly sure the app is not re-using previous codes, but utilizing the newly delivered codes for every new SMART instantiation. 

Are there additional coding steps required to be able to handle both access points with one App? Do apps commonly enable multiple access points? Any help in this regard would be greatly appreciated, thanks

[Aaron McGinn (Oracle Cerner)]

This information [1] may be helpful in the situation you are seeing!

It is not uncommon for an app to be used for both TOC and Organizer. There is a slight distinction in the workflows in that the TOC launch will be using patient scopes (i.e. patient/Encounter.read), whereas the Organizer-launched instance will be using user scopes (i.e. user/Encounter.read) since no patient is in context.

[1] https://fhir.cerner.com/millennium/faq/common-issues/#session-bleed-issue

-Aaron (Oracle Cerner)

[Gus Agudelo]

Yes..I was aware of that behavior, the problem is that after accessing the  app from the Organizer View, future invocations of the app from the patient TOC are returning the wrong patient scope. What I'm seeing is that after accessing from Organizer, If I open a patient, let's say Patient A, and access the app from Patient A's TOC, no patient scope is returned. Subsequently if I close Patient A, and open Patient B and access the  app from Patient B's TOC, the scope returned is for patient A (not B), and this pattern keeps on continuing for Patient C...D...E...etc, the scope returned is for the previous patient having been opened, not the current one. I've double checked my code and logs and the code  delivered to the app in the redirect URI, triggered by clicking the TOC access point,  is being returned back to the Millenium server for authentication, but the scope being returned during authentication is for the previous patient.  This erroneous pattern only begins happening after the first time the app is accessed from organizer,  before then, everything works fine. I can go back and forth among patients and always receive the proper patient scope. (I'm not using sessionStorage by the way, or noticed anything that may have applied to what I'm seeing in the bleed issue section you referred to).

Thanks,

Gus

[Aaron McGinn (Oracle Cerner)]

Can you provide a series of X-Request-Ids during this behaviour?

Which library and version are you using to consume the APIs?

-Aaron (Oracle Cerner)