Patient access - security considerations

[JohnMoehrke]

Pointed out that the recommendation for recording a search includes recording in the AuditEvent the security token. Even with short lived tokens, it is possible that

Given a clinician is working with a patient
and that clinician queries a FHIR server
and the BALP AuditEvent is recorded for that query
When the patient queries their AuditEvents
Then the patient will get the clinician token in the AuditEvent just recorded
And the patient may be able to use that token for impersonation of the clinician

It would not be proper to downgrade the AuditEvent for search, as that eliminates important information that the other audiences for audit query (Security office, Privcy office, Safety office, Operations office, etc). These audience may need to see the token so as to prove that access control was working or not.

So, a security consideration should be added to the audit query for this situation.

[JohnMoehrke]

is there anything in the .query and .description that is useful ever to a patient? The patient might see an interaction that is a concern, they could then bring that interaction to the attention of Privacy office for further detailed analysis (where the Privacy office would have full access to the AuditEvent and others around it).

[jkiddo]

It would be a goalmine of access tokens :)

[JohnMoehrke]

It would be a goalmine of access tokens :)

this is not a helpful comment. I am looking for useful profiling to support a patient access. This comment seems to be indicating that the patient has no right to this data.

[jkiddo]

Then you are not following my line of thought. The access token that goes into the AuditEvent could e.g. have its signature part removed when building the auditevent. Then there would be no issue.