Stream: Da Vinci PAS
Topic: SMART App
Hans Buitendijk (Dec 11 2019 at 19:13):
For questions/info on SMART App initiation, API access, related CDS Hooks, and what to receive back when authorized.
Hans Buitendijk (Dec 11 2019 at 19:14):
When the SMART App receives the authorization token/number from the payer, the suggestion is to use DocumentReference for now to document that in the EHR. We're looking whether there is a better alternative for HIMSS.
Nick Radov (Dec 11 2019 at 19:30):
I missed some of that discussion so I'm not sure I understand. Are you saying the SMART App would perform a REST create interaction to write a new DocumentReference in the EHR? Is that functionality widely supported by other EHRs? Would we actually store the token as an element in the DocumentReference, or would it merely serve as a record that the token had been received?
Hans Buitendijk (Dec 11 2019 at 19:32):
So far the suggestion is to provide the actual authorization token/number in DocumentReference.
Nick Radov (Dec 11 2019 at 19:36):
So far the suggestion is to provide the actual authorization token/number in DocumentReference.
Would that token go in securityLabel, content, or some other element?
Hans Buitendijk (Dec 11 2019 at 19:59):
@Nick Radov : content. Some are talking about a form that includes it.
Vassil Peytchev (Dec 11 2019 at 20:00):
This sounds quite contrived...
John Moehrke (Dec 11 2019 at 20:18):
not just 'quite contrived', but certainly NOT secure
Hans Buitendijk (Dec 11 2019 at 21:40):
Alternative suggestion? I can come up with some, but this is in context of HIMSS.
Hans Buitendijk (Dec 12 2019 at 17:05):
@John Moehrke : Can you clarify the security concern with DocRef using XHTML?
@Vassil Peytchev : ClaimResponse.preAuthRef with ClaimResponse.use=preauthorization and associated item(s) is appropriate, but not quite supported yet for HIMSS.
John Moehrke (Dec 12 2019 at 17:09):
I was referring to the point about putting a security token into a DocumentReference
John Moehrke (Dec 12 2019 at 17:10):
Placing a security token into any FHIR resource is a bad idea
Nick Radov (Dec 12 2019 at 17:12):
Placing a security token into any FHIR resource is a bad idea
Could you expand on this? What type of potential vulnerabilities could it cause?
Hans Buitendijk (Dec 12 2019 at 17:24):
@John Moehrke : We were actually talking about the prior-authorization reference number/token, definitely NOT a security token....:)
John Moehrke (Dec 12 2019 at 17:25):
AH, well then please don't use "authorization token". I know that might be the way that it is refereed to, but that phrase is far more broadly (whole of IT Security across the globe and all verticals) as security token.
Hans Buitendijk (Dec 12 2019 at 17:46):
@John Moehrke I had used "authorization token/number".....:)
Gunjit Chhatwal (Jul 12 2021 at 20:58):
PAS IG says "This will require that the provider system authenticates to the payer system or an intermediary. The specifics of how this authentication are covered is handled within the Da Vinci HRex Implementation guide". I am assuming this will not be launched in a patient context but will be a system-system kind of interaction. What type of grant type will be used for this exchange?
Josh Mandel (Jul 12 2021 at 21:42):
I'd expect a system/system interaction would use https://hl7.org/fhir/uv/bulkdata/authorization/index.html
Gunjit Chhatwal (Jul 13 2021 at 01:50):
right. would that be true for autheticating systems launching SMART on FHIR apps from CRD cards as those are not member/patient initiated?
Josh Mandel (Jul 13 2021 at 01:52):
If you are launching a user-facing app from a CDS Hooks card, that would typically use the SMART App Launch
Gunjit Chhatwal (Jul 13 2021 at 02:10):
since the user in this scenario is a provider, would the payer system then authenticate the system as a whole (SMART backend services) or just the user initiating the request. I believe latter would not be possible as the payers wont have provider's user credentials.
Josh Mandel (Jul 13 2021 at 02:19):
For the CDS Hooks API call, authentication would occur according to the CDS Hooks specification. This is essentially system level authentication where the client is the EHR and the server is the CDs provider.
For the app that gets launched from a CDS Hooks card, this would follow the SMART App Launch, where the EHR is the SMART server and the payer app is the client
Gunjit Chhatwal (Jul 13 2021 at 03:11):
I understand that the CDS hook API call would use JWT as per the CDS hooks specification. However, i did not understand the second point where EHR is the smart server and payer app is the client. So, the provider user would be authenticated again the EHR server? How would the payer app know that the it is being launched securely?
Josh Mandel (Jul 13 2021 at 03:14):
In SMART App Launch, the (payer) app connects directly to an SMART (EHR) server; at the first step of the process it learns the FHIR endpoint passed to the app via iss (generally the app maintains a list of configured FHIR endpoints where it's registered, and can check to make sure that the incoming value is on the list)
Gunjit Chhatwal (Jul 13 2021 at 03:24):
Understood. so the onus of authenticating the provider using the payer app (shared via card) is on the EHR launching the app and not on the payer. payer just needs to ensure that the system launching the app is one that it recognizes. Thanks, again.
Josh Mandel (Jul 13 2021 at 03:29):
Sure. And if the app wanted to authenticate the end user, it can lean on the EHR for this (by requesting openid fhirUser scopes).
Gunjit Chhatwal (Jul 13 2021 at 03:45):
Although I dont see the need to genrate a token using SMART on FHIR launch flow since the EHR is already sharing the token that can be used by the payer app to retrieve required details (per CDS specifications).
Josh Mandel (Jul 13 2021 at 13:39):
If the CDS token you're getting lasts long enough and you don't require a user authentication and you don't need any additional scopes, then you don't need to do a smart app launch. You can just link to an outside web page via CDS card. But using the smart app launch provides a consistent approach, making it less likely that you will inadvertently introduce mistakes into the flow --and allows you to take advantage of additional apis like smart web messaging for deeper interaction with the ehr.
Last updated: Apr 12 2022 at 19:14 UTC
