FHIR mistakes devs make #1: OperationOutcome

OperationOutcome does not always mean an error.

The first FHIR project I worked on, I built the backend that passed data from a FHIR server to a React app.

I made lots of mistakes, one of which was failing to understand the OperationOutcome resource.

I thought it signified an error.

I thought it meant my query had failed.

In some situations I would have been correct. But not in every situation.

To understand why, let’s look at the circumstances where the OperationOutcome resource is used.

1. When a REST call or operation fails
2. As a response to a $validate operation
3. As part of the response when a message has not been processed correctly
4. As the response to a transaction, when requested
5. As part of a search’s Bundle response containing information about the search

It was number 5 that caused difficulty for me and my code.

I didn’t know that my query could succeed, that I could receive a Bundle of perfectly valid FHIR resources, and that the same Bundle could include an OperationOutcome resource.

So I threw an exception and sent an error message to the React app.

What was the issue documented in the OperationOutcome?

The issue.details was “All OK” and the issue.severity was “information.”


If you are responsible for your own FHIR server, you may only send OperationOutcome resources when an error occurs. But you can’t assume the same of other FHIR servers.

The lesson here?

Always check the severity and code of an OperationOutcome before you assume an error. And don’t assume a Bundle of FHIR resources won’t ALSO include an OperationOutcome resource.

More: http://hl7.org/fhir/R4/operationoutcome.html



Sign up to “The Tuesday FHIR Sessions” and receive an email every Tuesday where I go deep on a single FHIR topic.