You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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.1traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-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.
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
andtracestate
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: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 fortraceparent
,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
The text was updated successfully, but these errors were encountered: