Is your feature request related to a problem? Please describe.
The Swiss national EPR will require the use of the traceparent HTTP header in future REST transactions (and backport it somehow into a SOAP header for the SOAP transactions).
I am looking for a way to integrate that value in the AuditEvents and saw that BALP was already supporting the somewhat similar X-Request-Id header.

Describe the solution you'd like
I am unsure: add a code for traceparent and tracestate in the CodeSystem and ValueSet BasicAuditEntityType, or add a more generic tracing identifier code?

Describe alternatives you've considered
None.

Additional context
Official specifications: https://www.w3.org/TR/trace-context/

The traceparent has a few advantages over X-Request-Id: it is a proper (W3C) specification, it supports flags to negotiate tracing behaviours, and allows for better transaction tracing by providing multiple identifiers: the trace-id (second part in traceparent) is constant for a given transaction, while the parent-id (third part) changes at each HTTP message (request, response). For example:

GET /Patient/$ihe-pix?sourceIdentifier=1 HTTP/1.1
traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-00

200 ok
traceparent: 00-0af7651916cd43dd8448eb211c80319c-00f067aa0ba902b7-00

In the case where the server is acting like an initiating gateway, it can also use the same trace-id to link the transactions together.

The Trace Context specification also defines the tracestate header, which is a vendor-specific header: its value is not standardized, but if support is added for traceparent, tracestate should be supported as well.

Related discussions on Zulip:
https://chat.fhir.org/#narrow/stream/179223-ihe/topic/.E2.9C.94.20Specify.20tracing.20identifiers.20in.20AuditEvents.20.28BALP.29
https://chat.fhir.org/#narrow/stream/179247-Security-and.20Privacy/topic/TraceID's