Clarify conventions (user & patient/subject characteristics etc)

[mcjustin]

Per https://cirg.slack.com/archives/C01P9V67NMA/p1735011973244129?thread_ts=1734983390.020329&cid=C01P9V67NMA here are the current conventions that we're moving to for COSRI:

{
  "patient": "Barney Abbott",
  "message": "overview tab",
  "level": "info",
  "tags": ["tab", "analytics", "cosri-frontend"],
  "patientName": "Barney Abbott",
  "subject": "Patient/5ee05359-57bf-4cee-8e89-91382c07e162",
  "user": {
    "username": "amysbubble",
    "DEA": "FAKEDEA123",
    "roles": [
      "clinician",
      "default-roles-femr",
      "offline_access",
      "uma_authorization"
    ]
  }
}

@pbugni I started to write this as a documentation request, but I don't understand a few things about the format...

1. What's the rationale for subject/patient not having a nested structure similar to the user?
2. Why are we recording so much subject/patient detail here? patient and patientName seem redundant with eachother, and it seems like having subject alone would suffice, unless we're trying to log a change to the patient's name.

  "patient": "Barney Abbott",
  "patientName": "Barney Abbott",
  "subject": "Patient/5ee05359-57bf-4cee-8e89-91382c07e162",

[mcjustin]

I think we should look to https://www.hl7.org/fhir/auditevent.html when making these decisions and follow that unless we have a good reason to not do so, especially for new work (e.g. let's talk tech).
Another guidance resource that was cited by most FHIR server vendors was https://profiles.ihe.net/ITI/BALP, which works in conjunction with AuditEvent; I took a brief look at that today, looks like some helpful patterns.

Adding @ivan-c here since I'm aiming to discuss this from the dhair2 side today (https://gitlab.cirg.washington.edu/svn/dhair2/-/issues/225)

[pbugni]

thank you @mcjustin for brining those 2 standards to my attention. i concur, we have too much repeated information, as well as unnecessary PHI in the audit examples you've included.

will work on adopting suggestions from the aforementioned standards and documenting best practices.

part of the challenge has been implementing logging for disparate use, where different sets of data are available based on context, as well as a stack with many moving parts, often lacking the details desired in the logs at the level of the triggering event.

[ivan-c]

The logserver doesn't have the same search functionality that a FHIR server has, and it may be difficult to write logserver (SQL) queries on FHIR data as things are set up now.

It's easy to write SQL queries on relatively flat JSON, but FHIR can contain embedded lists of resources (eg codings), and SQL doesn't have easy ways of searching/filtering those embedded lists.

For apps already working with FHIR, I think it makes sense to write AuditEvent entries. If the app implements FHIR, the app itself would be more capable to write and manage FHIR resources.

If there isn't a clear need for FHIR, there are some simpler standards from outside healthcare. However, they don't specify some key healthcare-specific elements (eg patient/provider). If we aren't going to follow a single standard, we could defer to AuditEvent where there are gaps in these simpler standards.

---

NIST SP800-92 - referenced by FHIR AuditEvent resource

Example Login Event

{
  "timestamp": "2024-12-30T12:34:56Z",
  "eventType": "LOGIN",
  "user": {
    "id": "user_123",
    "username": "jdoe",
    "role": "admin"
  },
  "action": "LOGIN_SUCCESS",
  "resource": {
    "type": "system",
    "id": "auth_server_01",
    "name": "Authentication Server"
  },
  "context": {
    "ipAddress": "192.168.1.100",
    "userAgent": "Mozilla/5.0",
    "location": {
      "city": "San Francisco",
      "region": "California",
      "country": "USA"
    }
  },
  "result": {
    "status": "success",
    "reason": null
  },
  "logDetails": {
    "logID": "log_56789",
    "source": "system_log",
    "integrity": "verified"
  }
}

IEEE 1849 another standard for event logs (sometimes called XES)

Example Login Event

{
  "cybox_objects": [
    {
      "type": "cyber_observable",
      "id": "event-12345",
      "created": "2024-12-30T12:34:56Z",
      "object": {
        "type": "event",
        "name": "User Login",
        "description": "A successful login to the authentication system.",
        "timestamp": "2024-12-30T12:34:56Z",
        "event_type": "login",
        "outcome": "success",
        "source": {
          "type": "system",
          "id": "auth_server_01",
          "name": "Authentication Server"
        },
        "actor": {
          "type": "user_account",
          "id": "user_123",
          "display_name": "John Doe",
          "account_login": "jdoe",
          "roles": ["admin"]
        },
        "network_information": {
          "ip_address": "192.168.1.100",
          "user_agent": "Mozilla/5.0"
        }
      }
    }
  ]
}