Provider App Type vs System App Type

90 views
Skip to first unread message

Mark Hatoum

unread,
May 25, 2018, 10:55:22 AM5/25/18
to Cerner FHIR Developers
Hi - I have been able to sucessfully setup and load a couple of sample SMART on FHIR apps in Cerner's Code console.

One of them uses the Provider App Type configuration, and the other is a System App Type. Both are working and load Patient data sucessfully in the test consoles.

Besides the obvious differences like the System App Type requiring a registration for App id and also being embedded in an iframe of an EHR, what are the key differences between the Provider App Type and System App Type? Are there any significant advantages using one over the other?

-Mark

Kol Kheang (Cerner)

unread,
May 25, 2018, 12:40:35 PM5/25/18
to Cerner FHIR Developers
Hi Mark,

It's great to hear that you've been able to play around with the apps in Cerner's code Console!

Depending on the app and the workflow scenario, one type may be better suited than the other.  If you don't have a user or your app doesn't require a user to log in to interact with the system (e.g. reporting, background running app), the system app is best suited for this!  You can learn more about it here: https://fhir.cerner.com/authorization/#requesting-authorization-on-behalf-of-a-system.  A system app does not have a user associated.  On the other hand, if users will be logging into the EHR and interact with the app or the app requires the presence of a logged in user, then the provider app is the best option.


Thanks,
Kol

Jenni Syed (Cerner)

unread,
May 25, 2018, 1:15:49 PM5/25/18
to Cerner FHIR Developers
It's also important to note that the system app type is not widely available yet in prod as mentioned in our overview and authorization registration pages.

In addition to the basic authorization differences of who is authorizing the app and the app is acting on behalf of (and that a system app is not embedded within the workflow/chart), there are other concerns an application may need to take on when using system access. For example, when an application is acting on behalf of a user (embedded or not within the chart), all of the auditing and sensitive data restrictions for that user are enforced and recorded. 

When acting on behalf of a system, we still do auditing that an application accessed data, but once it's into the other system, it is up to that system to audit who has accessed the patient data as well as enforce any sensitive data or privilege restrictions on that data.


~ Jenni
Reply all
Reply to author
Forward
0 new messages