Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

initial cut at schema compliant with FHIR AuditEvent #12

Draft
wants to merge 2 commits into
base: develop
Choose a base branch
from
Draft

initial cut at schema compliant with FHIR AuditEvent #12

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4ac4438
initial cut at schema compliant with FHIR AuditEvent
pbugni Jan 9, 2025
de6162f
minor edits and cleanup; `source` to include version info
pbugni Jan 15, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 50 additions & 2 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,10 +3,58 @@ API and storage for logging event and audit messages, persisted in JSON
within a PostgreSQL db, with a thin frontend provided by
[PostgREST](http://postgrest.org/en/v7.0.0/index.html)

The logserver serves as the **Audit Record Repository**, as detailed in the
Basic Audit Log Patterns
[(BALP)](https://profiles.ihe.net/ITI/BALP/volume-1.html#1-52-basic-audit-log-patterns)
implementation guide.

## Event Schema
**logserver** is agnostic to the format, provided it's valid JSON. Any number
of database tables can be used, but only the single **"events"** table is built
in, containing a PostgreSQL JSONB column, **"event"**.
of database tables can be used, but only the single `events` table is built
in, containing a PostgreSQL JSONB column, `event`.

It is desirable to generate log events complaint with the [FHIR audit event](
https://www.hl7.org/fhir/auditevent.html) resource. To generate an AuditEvent
resource nested within each `event` is cumbersome, however the following field
parity is recommended:

- `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.
- `code`: specific type of event. See [audit-event-sub-type valueset](
https://www.hl7.org/fhir/valueset-audit-event-sub-type.html) for full list.
- `login`
- `create`
- `read`
- `update`
- `delete`
- `search`
- `action`: required element to describe the type of operation performed.
- `C`: create - creating a new resource, such as adding a patient.
- `R`: read/view/search - data retrieved or viewed w/o modification.
- `U`: update - indicates existing data was modified.
- `D`: delete - indicates data was removed or deleted.
- `E`: execute - indicates execution of operation or procedure.
- `occurred`: defined only when reliance on message timestamp is inadequate
- `patient`: the **subject** of the activity, i.e. `Patient/ab-123-ef`
- `agent`: actor involved in the event, i.e. `Practitioner/123-abc`
- `source`: event reporter or system generating the audit event including version
- `entity`: data or objects used
- `detail`: tagged value pairs for conveying additional information
- `query`: query parameters for query-type entities
- `outcome`: result of event.
- `code`
- `fatal`
- `error`
- `warning`
- `information`
- `success`
- `detail`: additional outcome detail

## Historical Schema Information Below

The following suggestions for the format of each "event" entry enable common
query syntax and meet expectations.
Expand Down