Stream: Security and Privacy
Topic: audit.action for query
John Moehrke (Aug 01 2019 at 12:13):
Discussion has been going on in HAPI stream on auditing a query, and specifically what action vocabulary to use . Those involved are @Jens Villadsen @Grahame Grieve .. At issue is that today the specification, aligned with the DICOM Audit Event and ATNA, says to use the action "Execute" for a things including "..query/search". This is the pattern used in DICOM and IHE for an audit log message when the action was a query or search. This in contrast to what a native REST person would think it would simply be a "Read", as "Execute" would be for things like $operation. This REST perspective is logical to me, and if we were starting with no history I would put it this way... BUT there is history of 20 years of ATNA going back to RFC3881. So Although it is unusual for REST perspective, I would like to see it stay the way it is. I don't see an advantage to changing FHIR in this one way to be different, when there is really no benefit to the change.
discuss...
Grahame Grieve (Aug 01 2019 at 12:15):
I don't really think that the fundamentals are different - I think we use the words slightly differently, and we could just add clarifying language. FHIR Search - which is sometimes called query - is reading a set of resources that meet some predefined criteria. It's not really a 'query' in that ask the server to figure something out. We do have things like that, and they are E not R
Jens Villadsen (Aug 01 2019 at 12:20):
so 'Execute' is a catch-all phrase in the scope of computer science, right? Whether you read, manipulate or search or whatever, something is executed to some extent
Jens Villadsen (Aug 01 2019 at 12:21):
When you search or read or query, something is also executed, but to some extent it qualifies better as a 'read'
John Moehrke (Aug 01 2019 at 12:23):
a Read is pulling an identified resource... A search/query is providing parameters and asking for a set of resources that match the parameters. Hence why historically a query is handled as an execute, because it takes some processing to understand what the results would be
Jens Villadsen (Aug 01 2019 at 12:23):
so does a read ...depending of scope
Jens Villadsen (Aug 01 2019 at 12:24):
but I think we are sort of aligned here.
Jens Villadsen (Aug 01 2019 at 12:24):
Nevertheless, I would mark up 'execute' with operations that does not naturally qualify to other existing terms
Grahame Grieve (Aug 01 2019 at 12:25):
a read is a search with id = X
Jens Villadsen (Aug 01 2019 at 12:25):
yep
Jens Villadsen (Aug 01 2019 at 12:27):
I would like to see it changed to better match what is being done
Jens Villadsen (Aug 01 2019 at 12:29):
@John Moehrke I see your argument, I just don't buy it
John Moehrke (Aug 01 2019 at 12:33):
The problem is that to change it is to make a breaking change in the alignment with the standards from which it is derived.
Jens Villadsen (Aug 01 2019 at 12:36):
What is of most value to you/the community. Consistency to the terms or to the standards from which it is derived?
John Moehrke (Aug 01 2019 at 12:38):
the world is not pure FHIR... some audit record repositories will be receiving audit events from ATNA nodes, and some from FHIR nodes... I want the audit messages to be consistently understood.
John Moehrke (Aug 01 2019 at 12:39):
In IHE we have one definition for how to record a security relevant event, and the actor has the choice to record it using historic standards or FHIR.
Jens Villadsen (Aug 01 2019 at 12:39):
sure
John Moehrke (Aug 01 2019 at 12:40):
and we have a query of the audit record using FHIR AuditEvent API... which returns all audit log events regardless of how they were recorded.
Jens Villadsen (Aug 01 2019 at 12:43):
still - (disclaimer: strong generalization from my side) most developers => developers outside the healthcare perspective would probably think of a search as a read operation - not an execution.
John Moehrke (Aug 01 2019 at 12:47):
well, their audit logs would be recorded... they just might not be seen if a audit log analysis application is overly specific.. and I always remind audit log analysis applications to be very loose with their specifications so as to deal best with dirty data.
Lloyd McKenzie (Aug 01 2019 at 15:08):
In the end, the folks the audit most needs to make sense to is patients and care-givers. Which leads me to side with the "query = read" - because that's going to make sense to the person whose data it is. They could care less about ATNA or other standards. We break consistency with lots of HL7 standards too and it creates mapping challenges, but we do it when the end result is clearer and cleaner. I think that's the case here. "Execute" is a pretty poor term because it's all-encompassing - it seems like a generic abstract of all the other operations.
Grahame Grieve (Aug 02 2019 at 01:21):
I don't think we want to redefine anything. I think we just want to explain what words mean in what contexts
John Moehrke (Aug 02 2019 at 14:55):
The .type and .subtype elements are far more likely to be the ones shown to the user. The .action is just CRUDE. So I think the patient will be well informed... and caregivers are not the target audience of AuditEvent... the Privacy, Security, and Safety office are the target of the AuditEvent. clinicians are the target of Provenance
Grahame Grieve (Aug 02 2019 at 21:49):
is that policy? or just likely? if it's useless such that we don't care about it, why does it exist?
Last updated: Apr 12 2022 at 19:14 UTC
