Openemr: FHIR Resource response incorrect.

[sjpadgett]

Describe the bug

Currently any of our FHIR API responses emitted to interface is of the form:

{
  "validationErrors": [],
  "internalErrors": [],
  "data": {
    "id": "92328288-92ed-4b97-b15a-22ccc257a992",
    "meta": {
      "versionId": "1",
      "lastUpdated": "2020-12-17T17:17:03+00:00"
    },
    "resourceType": "Patient",
    "text": {
      "status": "generated",
      "div": "<div xmlns=\"http:\/\/www.w3.org\/1999\/xhtml\"> <p>Jason Binder<\/p><\/div>"
    },...

Unsure why it is done this way essentially combining an Operation Outcome with the response json.
The Operation Outcome should be sent if an error as a different resourceType.

{
  "resourceType": "OperationOutcome",
  "id": "101",
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n      <p>The code &quot;W&quot; is not known and not legal Patient.gender.</p>\n    </div>"
  },
  "issue": [
    {
      "severity": "error",
      "code": "code-invalid",
      "details": {
        "text": "The code \"W\" is not known and not legal in this context"
      },
      "diagnostics": "Acme.Interop.FHIRProcessors.Patient.processGender line 2453",
      "location": [
        "/f:Patient/f:gender"
      ],
      "expression": [
        "Patient.gender"
      ]
    }
  ]
}

Also interesting is why are we sending the resource response inside a data array!

 "data": {
    "id": "92328288-92ed-4b97-b15a-22ccc257a992",
    "meta": {

For example should be:

{
  "id": "92328288-92ed-4b97-b15a-22ccc257a992",
  "meta": {
    "versionId": "1",
    "lastUpdated": "2020-12-17T17:35:00+00:00"
  },
  "resourceType": "Patient",
  "text": {
    "status": "generated",
    "div": "<div xmlns=\"http:\/\/www.w3.org\/1999\/xhtml\"> <p>Jason Binder<\/p><\/div>"
  },
  "identifier": [{
    "use": "official",
    "type": {
      "coding": [{
        "system": "http:\/\/terminology.hl7.org\/CodeSystem\/v2-0203",
        "code": "SS"
      }]
...
}

@dixonwhitmire Do you have a comment? Unclear but I believe you set this up or maybe have an insight.

[dixonwhitmire]

Hi @sjpadgett - Yes if this is occurring this is not compliant with the FHIR R4 spec.

The first response payload you mention looks similar to the API response which is documented here. This API response is used for the OpenEMR "non-FHIR" endpoints.

If I remember correctly, and I'm stretching here as this was "pre-paternity leave" is that the FHIR Controllers would be able to convert to/from OpenEMR "standard record" types as needed. What's perplexing is that the FHIR Patient Test Case is validating the standard API response fields. It looks like I either forgot to extract these fields from the response, or I planned to do so in a later iteration, which I never completed.

@yashrajbothra - Did the FHIR endpoints you worked on include these "standard response fields" (validationErrors, internalErrors, data), or were they FHIR R4 compliant?

[sjpadgett]

I'll get it sorted. Just wanted to ensure there wasn't a reason it worked this way. This needs to be broken up.
Thanks.

[sjpadgett]

This was fixed as companion in another PR.