1

Is it appropriate to return an OperationOutcome for an entry when we are not able to fully populate the optional fields due to technical limitations rather than data availability? If so, how do we do that?

I read up the documentation on the usage of OperationOutcome, but I think what I understood was that OperationOutcome with search.mode = 'outcome' can only be used when there is search failure and instead of populating the entry with the requested resource you should have searchset with the entry of OperationOutcome resource with search.mode = 'outcome' in the response from the server. And OperationOutcome should state the reason of the failure.

In this case we do not have a complete search failure, but have a partial failure where we are not able to fully populate the optional fields due to technical limitations.

Thanks

Davis Christi
  • 15
  • 2

1 Answers1

0

It's acceptable to include an OperationOutcome as one of the entries in a query response bundle along-side the entries containing results of executing the search.

Possible reasons for doing this is if a search is expected to be executed against multiple repositories but some of the repositories couldn't be reached. Another is where you may want to explicitly warn that the results have been filtered or partially suppressed for security/consent reasons (if you're in a situation where the user has the right to know that.)

Bundle.search.mode exists so you can easily differentiate what results are from your search as opposed to being warnings contained in an OperationOutcome.

(If you can point to wording that's confusing, feel free to submit a change request so we can make the spec clearer.)

Lloyd McKenzie
  • 6,345
  • 1
  • 13
  • 10
  • So, We can include OperationOutcome resource as one of the entries when search as a whole had issues and all the entries on the response bundle were affected by it. Our Scenario: When we populate query response bundle entries, only for some of the entries we are not able to fully populate optional fields due to technical limitations, but for all the other entries, we are able to populate those fields. So would it be advisable to have OperationOutcome resource as a separate entry in the response bundle that would state that these particular entries have certain fields not populated. – Davis Christi Jan 28 '16 at 21:07
  • e.g. For a DiagnosticReport search request, the server is able to find multiple DiagnosticReports that qualify for the search, however, populating bundle entries on response, for some of the entries, some of the fields (e.g. meta, conclusion) on the resource, we are not able to populate those but can populate all the other remaining fields on that entry. For other entries we are able to populate them. So what ends up happening is in the bundle response from the server, we have some entries with all the fields populated some entries with partial data (fields meta, conclusion not present). – Davis Christi Jan 28 '16 at 21:10
  • I would probably include a single OperationOutcome that indicated that "some" resources had missing fields. If you wished (and you though any systems would support it), you could have an extension on the OperationOutcome that pointed to the specific resources that had the issue, but I'm not sure the benefit to the end-user would be worth the complexity. You'd have to evaluate that for your implementation circumstance. – Lloyd McKenzie Jan 29 '16 at 00:41