initial cut at schema compliant with FHIR AuditEvent #12
Conversation
There was a problem hiding this comment.
Good move in my eyes. For unspecified information that might be necessary to log (ip address, user agent, session id) would we extend this schema at the top level, or would we expect additional data elements in one of the detail fields?
Not being super familiar working with the old schema, was its tag support not useful, too inconsistent, or is its function just adequately replaced by other fields in the new schema?
README.md
Outdated
| - `category`: major type of the event, such as: | ||
| - `authentication`: events related to login or authentication. | ||
| - `authorization`: events related to access control or permissions changes. | ||
| - `security`: general security-related events. | ||
| - `data-access`: events where healthcare data is accessed or modified. | ||
| - `configuration`: events involving system or configuration changes. |
There was a problem hiding this comment.
Would we just omit if the logged event doesn't fit into these five buckets?
There was a problem hiding this comment.
we opted to do away with category as it's generally captured by action
README.md
Outdated
| - `patient`: the **subject** of the activity, i.e. `Patient/ab-123-ef` | ||
| - `agent`: actor involved in the event, i.e. `Practitioner/123-abc` |
There was a problem hiding this comment.
There was a brief discussion last week around the need for field type consistency for ELK to index records properly, and user/subject came up as one that sometimes may be easier to include as a string (id) but other times may be included as an object (with additional user information, secondary IDs, etc.), and some systems may have access to only one or different identifiers than others for the same user. With this schema, would we move toward simplifying to the most appropriate string for the system, or would we fudge the FHIR a bit and include some info as a more complex data type?
There was a problem hiding this comment.
a hybrid, if you will. consistent FHIR reference strings where possible. i.e. <ResourceType>/<primary_key>
There was a problem hiding this comment.
dhair2 implementation according to this PR here: https://gitlab.cirg.washington.edu/svn/dhair2/-/merge_requests/875 , examples of log entries there at https://gitlab.cirg.washington.edu/svn/dhair2/-/merge_requests/875#note_20490
|
@ivan-c please feel free to add review comments - i can create another PR if necessary. For now, probably best to merge this for easier reference by others. |
No description provided.