Stream: implementers
Topic: Operation Log
Grahame Grieve (Oct 23 2018 at 22:43):
Here's a specific question that might need a general answer. I'm working with @James Agnew to add version conversion to the hapi.fhir.org server. It would work like this, following the spec:
Grahame Grieve (Oct 23 2018 at 22:44):
POST /base/$convert Accept: application/fhir+json; fhirVersion=3.0 Content-Type: application/fhir+json; fhirVersion=4.0 <body>
where body = R3 resource and a R4 resource would be returned (or could be the other way)
Grahame Grieve (Oct 23 2018 at 22:44):
the conversion operation produces a fairly voluminous log that could be pretty interesting for the client to get hold of
Grahame Grieve (Oct 23 2018 at 22:45):
it seems to me that the right way to do this would be for the server to store the log in an AuditEvent, and put a link in the HTTP return headers that identifies the relevant AuditEvent, like so:
Grahame Grieve (Oct 23 2018 at 22:47):
Link: <AuditEvent/23123123>; rel=archives
Grahame Grieve (Oct 23 2018 at 22:48):
archives looks like the least inappropriate defined rel type, but it's still pretty wrong. So:
Grahame Grieve (Oct 23 2018 at 22:48):
Link: <AuditEvent/23123123>; rel=audit
Grahame Grieve (Oct 23 2018 at 22:48):
does this make sense to people?
Brian Postlethwaite (Oct 27 2018 at 01:32):
Assuming this is for a multi-version capable server
Christiaan Knaap (Dec 17 2018 at 11:21):
If it is really relevant for the client to know about, why not return the result + log in a bundle? Or a Parameters resource - that is designed for an operation response? Less chance of ignoring important information.
Last updated: Apr 12 2022 at 19:14 UTC
