Stream: Da Vinci DTR
Topic: security considerations in DTR
Sreekanth Puram (Oct 14 2021 at 02:59):
hi @Lloyd McKenzie , I think as a group we never focussed much on the security portion for any of the Da Vinci IGs in detail at any point. Hence during an overall security sweep, the issue that was brought up during this morning's call can be addressed. We at Mettle, in our workflow already implemented the feature of saving and retrieval of Questionnaires. Since there was no standard, we were implementing it in our own way and will change our implementation based on the standards that will be addressed.
Regarding security, we currently implement three layers of security. Again this is not the standard way of implementation but had to put in some sort of mechanism to get the appropriate ISO information security certifications. I am presenting the methodology that we use but will be happy to change it once we get a standard way defined by Da Vinci.
- To prevent man-in-the-middle attack, we use the standard TLS encryption for any data that is transmitted between two parties in any direction for all the IGs.
- To identify the application which invoked an FHIR request (get/post/put) we use the client credentials flow.
- In addition to the above two, for communication between providers and payers through an external SMART application, we also include an access token with the appropriate scope from the EHR. The payer/intermediary endpoint which receives the FHIR request will verify the access token with the EHR to confirm the authenticity of the incoming request. For FHIR requests which don't create new resources on the FHIR endpoint, we also make sure that the scope available for the access token supplied is same as the scope allowed for the access token that created the resource. This may or may not be the standard way of doing things, but it covers the security requirements for getting an ISO 27001 Certification for information security. so we implemented this mechanism.
The payer/intermediary which stores the information has a list of predefined EHR verification systems against which that can verify the access token along with the scopes that it carries. This list can be updated periodically as needed.
We would love to get your feedback on this and will change our process to meet the standard. However, the bottom line here is that we can find some way to establish the authenticity of the incoming requests at the payers end which stores the data.
Lloyd McKenzie (Oct 14 2021 at 03:09):
For step 2, are you talking about requests to the EHR or requests to the payer? What we're introducing is the latter. If you're referring to app-to-payer, can you expand on what "client credentials flow" is?
The challenge that we have is:
- the app could be any SMART app that implements DTR (though we could enforce that the payer must 'trust' the app and there could possibly be a shared secret)
- shared secret isn't super robust though. If anyone gets hold of the code for the SMART app, they could learn that secret and impersonate the app
- payer isn't part of the SMART Oauth process and won't be known to the auth server.
Sreekanth Puram (Oct 14 2021 at 03:24):
I am talking about the app to the payer. The client credentials flow would require that we use a client id and client secret to authenticate a client which is accessing a FHIR endpoint. Instead of using a clear text client secret, we can use a signed key (a JWT) as a client secret. The signed key will be obtained dynamically from the app vendor's endpoint after checking the authenticity of the EHR under which the app is being invoked.
As mentioned in step 3: If the payer does not trust the app vendor alone, they should be able to verify the authenticity of the EHR/Hospital system which invoked the smart app in addition to verifying the mart app.
Lloyd McKenzie (Oct 14 2021 at 03:39):
I'm not understanding the flow. We're talking about securing the connection from SMART app to payer. How is the EHR involved at all? And how is the vendor involved? Do you have a flow diagram?
Sreekanth Puram (Oct 14 2021 at 05:12):
@Lloyd McKenzie please find the image for the provider side auth workflow below
provider_side.jpg
Sreekanth Puram (Oct 14 2021 at 05:14):
And the payer side workflow below payer_side.jpg
Lloyd McKenzie (Oct 14 2021 at 12:35):
Ok, so you're passing the access token given to the SMART app to access the EHR along to the payer to govern what the app is allowed to access. That may be sufficient. Even if the credentials the app uses to sign its JWT are compromised, an app can't do anything unless it's launched by an EHR (which means you can't just stand up your own app and start hitting payer) and the app can only access the data for the specific patient the app was launched for). If the app is launched without patient context, then it won't have permission to access any of the stored DocumentReferences.
Sreekanth Puram (Oct 14 2021 at 13:34):
That's correct. There may be few other methodologies that we may come up with if we do a security sweep of all the Implementation guides.
John Moehrke (Oct 14 2021 at 16:07):
I think your approach is proper and what I would recommend. the shared secret is what is supported today, UDAP will bring in better approaches. I would recommend DaVinci always defer to the security IGs, and the security checklist in the core spec.
Lloyd McKenzie (Oct 14 2021 at 16:18):
The security checklist doesn't nail down the validation mechanisms. Certainly we need to point to it as a starting point and to cover generic stuff, but we need to constrain and be tighter to ensure interoperability and raise the bar in certain places. UDAP presumes application registries, which I don't think we're going to have...
John Moehrke (Oct 14 2021 at 18:18):
agreed. glad to get improvement requests for the FHIR core security pages.
Matt Varghese (Oct 14 2021 at 18:24):
What is the benefit of the Payer receiving the Access Token issued by the EHR for the App?
Can then payer somehow tell which patient's/user's etc. scope the access token has?
Or is the payer required to validate that the given access token can be used to read the specific patient from the EHR before returning a response?
Sreekanth Puram (Oct 14 2021 at 18:37):
In addition to checking whether the request came from a valid app, the payer also needs to make sure that the app is not invoked outside the EHR from which it was launched when it created the DocumentReference. The patient/user context can be retrieved from the access token. Again this is one way of solving the problem of client secret getting misused. There may be other mechanisms.
John Moehrke (Oct 14 2021 at 18:38):
minimally it is useful to record in the audit log the triggering user and purpose. Often the user is not used in an access permit/deny decision.
Lloyd McKenzie (Oct 14 2021 at 19:16):
Yes - the payer would absolutely be needing to enforce the same patient scope. Best way to do that is probably to have the DocumentReferences on the payer be absolute references to the EHR's Patient (rather than the payer's member). Then there's should be no need for the payer to query the EHR to check the token or try to resolve patient's resource id to payer's member id.
Lloyd McKenzie (Oct 14 2021 at 19:17):
In our case, we'd absolutely want to use it in permit/deny - so a malicious app can't query any other patient's data than the specific one the user of the SMART app is trying to access.
Matt Varghese (Oct 14 2021 at 22:36):
Then there's should be no need for the payer to query the EHR to check the token or try to resolve patient's resource id to payer's member id.
Are you saying then that the DTR App cannot do a DocumentReference Search; only a DocumentReference read? I can't see how that would work, since the DTR App will not have the ID of the DocumentReference.
And if Search is available, most implementations don't allow scoping for search on only some search params, and not other search params.
So as long as the DTR App needs to be able to do a DocumentReference search, it would not be safe until the payer validates the token, and verifies that the patient is the same patient in the EHR scope?
Lloyd McKenzie (Oct 14 2021 at 22:37):
It can do a search, but it needs to be limited to only searching for the DocumentReferences for the current patient.
Matt Varghese (Oct 14 2021 at 22:37):
There is no "current patient" on the payer side. Only the EHR side has a "current patient"?
Lloyd McKenzie (Oct 14 2021 at 22:39):
The 'current patient' is identified in the token from the EHR. We will need to find a way to pass that same token to the payer - possibly in a new header. (It's not a 'regular' auth token as it's not for the payer's system.)
Matt Varghese (Oct 15 2021 at 01:09):
Would that do anything, unless the payer validates with the EHR that the current patient it was passed is indeed the patient the EHR has open?
Lloyd McKenzie (Oct 15 2021 at 01:42):
The token from EHR to smart app has a limited time-span and would have had to have been in the app's "hands" to query with in order for it to re-use later, so it can't really access anything it wouldn't have already had access to in that scenario.
Matt Varghese (Oct 15 2021 at 02:04):
That is the case when the app is a real app.
But if the app is a malicious app, it can just pull out a token and a current patient ID from thin air, and then do a DocumentReference search for perhaps something like all DocumentReferences Authored by XYZ Clinic.
If the payer doesn't validate the token, and the patient and find that the token and patient are not real, this is not doing any good?
Lloyd McKenzie (Oct 15 2021 at 02:33):
The payer will need to validate the token. I don't understand why it would also need to validate the patient. If the token was valid, why would the patient not be?
Sreekanth Puram (Oct 15 2021 at 04:01):
Lloyd McKenzie said:
The payer will need to validate the token. I don't understand why it would also need to validate the patient. If the token was valid, why would the patient not be?
The payer needs to validate the token and should be able to extract information about the logged-in user, patient, etc.
For non-popular EHRs or practice management systems, the payer should also have a list of other third-party authentication tools like Auth0, AWS Cognito, etc that they trust.
The other option is for the EHR to provide a digitally signed key with timestamp on demand for the apps which run within its scope. That way, the payer can always verify if the call comes from a EHR invoked app or a malicious app.
Lloyd McKenzie (Oct 15 2021 at 04:08):
Apps can change, so what's not malicious today might become ill-behaved. Our mechanism needs to ensure that the payer can limit the app to only seeing stored information relevant to the patient the EHR feels is in context.
Sreekanth Puram (Oct 15 2021 at 16:31):
@Lloyd McKenzie I am just thinking out loud. Can we use the same mechanism to handle the problem of Alert fatigue where the payer stores the app context and other metadata for every CRD requestby default? So in case, the provider misses the alert arising out of the response to CDS hooks, the provider or the back-office staff can launch a SMART app and start the DTR process at a later stage also.
Lloyd McKenzie (Oct 15 2021 at 16:53):
I don't think storing the information addresses alert fatigue. Alert fatigue is addressed by ensuring that the card is only passed back when there is DTR information to fill out that a) should be filled out now; and b) should be filled out by the current user. However, in those cases where the provider opts not to launch DTR right now (e.g. they're too busy), then yes, we could cause it to be automatically stored.
Last updated: Apr 12 2022 at 19:14 UTC
