How do OperationOutcomes get returned from the Data Receiver?

[cooperthompson]

Per the Data Receiver Requirements page:

The Data Receiver SHALL validate the received NDJSON data according the UDS+ FHIR IG profiles and return OperationalOutcomes for each instance of conformance failure.

and

The Data Receiver SHALL apply necessary business rules to check data quality and provide feedback via OperationalOutcome for each data quality issue. These may be errors or warnings.

The IG doesn't appear to define an operation for the status polling URL. It just mentions that such a thing exists, and has an example. In that example, a successful import will return a single OperationOutcome, while a failure will return a JSON array of OperationOutcomes.

Could we define a submission status operation so there is a clear spec around what the content looks like? Using an example to reverse engineer what is expected makes me uncomfortable. It doesn't necessarily need to be an OperationDefinition, but at least something like the Bulk FHIR IG has for the status polling, with clear inputs and outputs and status codes. Also, can we have the response consistently be an array, so submitters don't have to create two different response handlers and somehow figure out which one to use? And the operation could also define the valid HTTP status codes. The Bulk Data Status Request operation, uses 202 and 200 to differentiate between in progress and complete.

[nbashyam]

Cooper,

We will add clarity to the Status polling similar to the Bulk Data Status Request Operation. Thanks for the feedback. The OperationOutcome from the status polling will be clarified to always be a single OperationOutcome resource with a list of issues within the OperationOutcome. This will be consistent with the Bulk Spec and the Pattern also. We will add an extension to provide pagination within the OperationOutcome if the # of issues are more than what could be easily accomodated in a single query. Any suggestions on the pagination are welcome.

[cooperthompson]

The approach of always having a single OperationOutcome fine. Though if we need to do pagination, I wonder if a Bundle might be better, since that already has built-in and familiar options for paging. With a Bundle though, you'd want individual OOs for each issue, since the paging would be across OO resources, not issue within the OO.

The paging issue is something I didn't consider when proposing that we mirror the Bulk FHIR status polling approach.

I honestly don’t object to the non-FHIR JSON wrapper approach you have today. If you want to stick with that for the short term, I'm ok with it. The main thing I want is to either always have that wrapper, or never have it. Having the response sometimes be a JSON file with an array, and sometimes be just an OO is the variability I wanted to avoid.

[nbashyam]

Thanks for the feedback Cooper, we will make a decision on the Bundle vs the wrapper that we currently have and update the IG shortly.

[cooperthompson]

Also, another consideration in Bundle vs. JSON wrapper, is that if we use Bundle, then if a system wants XML rather than JSON, presumably that could be supported. Though I suppose if you do pick the Bundle option, you'll want to document whether you support XML and JSON or just JSON.