JIRA Ticket:
BB2-1966

What Does This PR Do?

Passthrough FHIR OperationOutcome response to API caller

What Should Reviewers Watch For?

If you're reviewing this PR, please check for these things in particular:

Validation

1. Check out the PR and spin up a local bb2 server
2. Passing tests not required since some tests break due to the changes
3. Create a user e.g. U001, and add an app under the user e.g. MyApp001
4. Use the swagger UI to authorize e.g. BBUser00000
5. Upon authorize success, do a FHIR query, e.g. GET Coverage with resource id
6. For BBUser00000, there is a coverage with ID: part-b--10000010254618
7. { "resource": { "resourceType": "Coverage", "id": "part-b--10000010254618", "meta": { "lastUpdated": "2023-06-14T18:17:07.293+00:00", "profile": [ "http://hl7.org/fhir/us/carin-bb/StructureDefinition/C4BB-Coverage" ] }, "extension": [ {
8. Do a GET Coverage with resource_id like shown below:

10. Should see response: Coverage
11.

12. Now change the resource_id value to: part-b_______--10000010254618, a malformed coverage ID, and execute the GET Coverage, you will get a OperationOutcome resource indicating a 400 situation : Bad parameters

Above demonstrates the new behavior of FHIR endpoints passthrough the FHIR OperationOutcome to the API caller

What Security Implications Does This PR Have?

Please indicate if this PR does any of the following:

• Adds any new software dependencies
• Modifies any security controls
• Adds new transmission or storage of data
• Any other changes that could possibly affect security?

• Yes, one or more of the above security implications apply. This PR must not be merged without the ISSO or team
  security engineer's approval.

Any Migrations?

• Yes, there are migrations
  • The migrations should be run PRIOR to the code being deployed
  • The migrations should be run AFTER the code is deployed
  • There is a more complicated migration plan (downtime,
    etc)
• No migrations