Stream: implementers
Topic: Returning DiagnosticReport + Audit Information
Neil Grooby (Nov 15 2016 at 04:16):
We are looking at being able to return a DiagnosticReport resource but we also need to return some additional information:
- The diagnostic file information - this we can handle by just not returning the data in the Attachment
- When the file was downloaded and by whom - this might be an auditting function but we want to return this too. This will consist of 0..n records containing date/time + Name (string)
One consideration would be to create a BUNDLE with these in it. We also need to return an array/List of both of these as part of search criteria based on date criteria.
Is this the most appropriate way of returning this, or is there a better way - we are returning a file as evidence to a third party and need to track what other people from their organisation may have downloaded it previously via the software (not the FHIR interface)
Grahame Grieve (Nov 15 2016 at 06:59):
Well, AuditEvent is the resource for the list of who viewed it and when.
Grahame Grieve (Nov 15 2016 at 07:00):
but it's not clear what you mean when you say 'return'
John Moehrke (Nov 15 2016 at 13:07):
It seems you might be describing a use of AuditEvent. You could certainly bundle AuditEvent resources the same way you would bundle anything else. AuditEvent is there to record any event, so viewing, importing, exporting, as well as other audit relevant things like login/logout/configure/startup/shutdown.
You might also want to look at Provenance; as it is intended to explain where data came from. It thus is more closely tied to the RESTful Create and Update (AuditEvent often will duplicate these events for audit purposes vs provenance purposes).
John Moehrke (Nov 15 2016 at 13:12):
I am not understanding your first bullet on diagnostic file not containing something. There is meta tag that should be used when you don't give the full content of a resource - SUBSETTED. This tag helps downstream receivers understand they don't have the full truth. http://build.fhir.org/v3/SecurityIntegrityObservationValue/cs.html#SUBSETTED
Neil Grooby (Nov 15 2016 at 22:12):
Thanks John and Grahame.
We have a historical API which we are moving to FHIR where we will call the FHIR API version of the primative for new callers.
For historical backward compatibility reasons we will also callthe same FHIR API version and create the old API datacontracts to allow existing customers to use their existing solutions until they migrate to the FHIR equivalent.
For the above we have an API which gets a list of finalised DiagnosticReports within a search range - this includes the filesize, so Attachment has this ability. The data of Attachment can be non-present allowing us to pass back the metadata we require. We are comfortable that DiagnosticReport does the majority of the work for the API.
Using a Bundle with AuditEvent and DiagnosticReport would be perfect - we can return a List of the Bundle where needed
Last updated: Apr 12 2022 at 19:14 UTC
