Single Patient API - (3) of the 4.2 Patient resource test fail due to the array order when multiple names (FI-1599)

[dhit-mdavis]

Hello.

• When there are multiple names for a Patient and the data-absent-reason is the first entry in the array, the following 3 tests fail

• Previously, with Inferno Legacy, the same FHIR resource data passes with no issue.
• It appears that Inferno Legacy may have been either skipping the data-absent-reason entry
• or it may have been iterating over the name array until it found an entry that met a certain criteria
• Either way, this feels like an issue that needs to be addressed

Inferno v2 fails - Inferno Legacy Passes Here is a FHIR Resource example

"name": [
      {
        "extension": [
          {
            "url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
            "valueCode": "unknown"
          }
        ]
      },
      {
        "use": "official",
        "text": "Johnny LastName",
        "family": "LastName",
        "given": [
          "Johnny"
        ]
      }
    ],

Inferno v2 passes - Inferno Legacy Passes Here is a FHIR Resource example

    "name": [
      {
        "use": "official",
        "text": "Johnny LastName",
        "family": "LastName",
        "given": [
          "Johnny"
        ]
      },
      {
        "extension": [
          {
            "url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
            "valueCode": "unknown"
          }
        ]
      }
    ],

Please let me know your thoughts

Thanks - Mat

[yunwwang]

hello @dhit-mdavis: This is an interesting issue. When you put the DAR extension in an array, like your first example, what is the meaning you want to convey?

[dhit-mdavis]

Hi @yunwwang. Here's the C-CDA view of the same data before it gets converted to FHIR. Let me know if this helps answer your question

    <name>
      <given nullFlavor="NI" />
      <family>LastName</family>
    </name>
    <name>
      <given qualifier="BR">Johnny</given>
      <family>LastName</family>
    </name>

[yunwwang]

@dhit-mdavis :

The meaning of the XML presentation and JSON presentation are different:

In XML presentation: The patient has two names. We only know the family name of the first of his two names. In JSON presentation, the DAR extension causes some confusion on the precise meaning of this array. That is why I asked. One interpretation (I think this is the correct interpretation) is that: The patient has two names. We don't know the first of his two names.

The correct JSON presentation of the XML name array is

"name": [
  {
    "family": "LastName"
  },
  {
    "use": "official",
    "text": "Johnny LastName",
    "family": "LastName",
    "given": [
      "Johnny"
    ]
  }
]

We will investigate if we could improve our test to handle that.

[dhit-mdavis]

Thank you @yunwwang for that info. I think it was helpful from my perspective.

"We will investigate if we could improve our test to handle that."

• I appreciate this

So the question is now, how will Inferno v2 handle the correct JSON presentation array you illustrate? I'm going to look into performing a test case using the info below and update here once completed.

[dhit-mdavis]

Hi @yunwwang. Apologies for the delay in this follow up. Here are my results.

1 - I adjusted the FHIR output to represent the interpretation that you mentioned above

2 - In doing so, I was able to pass the following sub tests for the Single Patient API Patient resource section. However, I now end up failing the very last test section, 4.32 Missing Data Tests

What are your thoughts on this outcome?

Patient Resource

Missing Data

[yunwwang]

You can use any resource for missing data test, not just Patient. For example, if this Patient has an Observation which contains a DAR extension. That would pass the DAR extension test.

[dhit-mdavis]

Thank you @yunwwang. I'll bring this back and keep you informed.

Otherwise, let me know if it's my responsibility to close a ticket then I will for now

[yunwwang]

We are still looking at our handling of DAR extension. Please keep this ticket open.

[dhit-mdavis]

Roger that and I will leave it open for the time being. Thanks as always!

[yunwwang]

We have identified the issue that Inferno could not retract search value when the first array item is an element with DAR extension. The fix is in the Pull Request mentioned above.

[dhit-mdavis]

Thanks for that update!

[monicasmith2022]

https://github.com/onc-healthit/onc-certification-g10-test-kit/issues/142

[monicasmith2022]

Would you please confirm if a skip is synonymous with a failure? We have encountered quite a bit of them. See below: .2 Patient Tests i. Test can provide correct responses for patient queries. These queries must contain resources conforming to the US Core Patient Profile as specified in the US Core v3.1.1 Implementation Guide. ii. 4.2.07 Server returns Provenance resources from patient search by_id + revInclude Provenance : target iii. 4.2.09 All must support elements are provided in the Patient resources returned iv. 4.3.03 Server returns Provenance resources from AllergyIntolerance search by patient + revinclude Provenance target v. 4.3.05 All must support element are provided in the AllergyIntolerance resources returned

2. 4.4.03 Server returns Provenance resources from AllergyIntolerance search by patient + revinclude Provenance target i. 4.4.05 All must support elements are provided in the CarePlan resources returned
3. 4.5 CareTeam Tests i. 4.5.03 Server returns Provenance resources from CareTeam search by patient + status + revinclude: Provenance: target
4. 4.6.03 Server returns Provenance resources from Condition search by patient + revinclude Provenance target
5. 4.7 Implantable Device Tests i. 4.7.01 Server returns valid results for Device search by patient ii. 4.7.02 Server returns correct Device resource from Device read interaction iii. 4.7.03 Server returns Provenance resources from Device search by patient + revInclude:Provenance: target iv. 4.7.04 Device resource returned during previous tests conform to the US Core Implantable Device Profile v. 4.7.05 All must support elements are provided in the Device resources returned vi. 4.7.06 MustSupport references within Device resources can be read
6. 4.8.06 Server returns correct DiagnosticReport resource search by patient + category + revInclude Provenance target
7. 4.9 DiagnosticReport for Laboratory Results Reporting Tests i. 4.9.06 Server returns Provenance resources from DiagnosticReport search by patient + category + revInclude:Provenance target ii. 4.9.09 MustSupport references within DiagnosticReport resources can be read
8. 4.10 DocumentReferences Tests i. 4.10.07 Server returns Provenance resources from DocumentReference search by patient + revInclude: Provenance:target
9. 4.11.03 Server returns Provenance resources from Goal search by patient + revInclude:Provenance:target i. 4.11.05 All must support elements are provided in the Goal resources returned ii. 4.11.06 MustSupport references within Goal resources can be read
10. 4.12.03 Server returns Provenance resources from Immunization search by patient + revInclude:revInclude:Provenance:target i. 4.12.05 All must support elements are provided in the Immunization resources returned
11. 4.13 MeidcationRequest Tests i. 4.13.01 Server returns valid results for MedicationRequest search by patient + intent ii. 4.13.02 Server returns valid results for MedicationRequest search by patient + intent + status iii. 4.13.03 Server returns correct MedicationRequest resource from MedicationRequest from MedicationRequest read interaction iv. 4.13.04 Server returns Provenance resources from MedicatioRequests search by patient + intent+ revInclude:Provenance:target
    v. 4.13.05 MedicationRequest resources returned during previous tests conform to the US Core MedicationRequest Profile vi. 4.13.06 Medication resources returned during previous tests conform to the US Core Medication Profile vii. 4.13.07 All must support elements are provided in the MedicationRequest resources returned viii. 4.13.08 MustSupport references within MedicationRequest resources can be read
12. 4.14 Smoking Status Observation Tests i. 4.14.03 Server returns Provenance resources from Observation search by patient + code + revInclude:Provenance:target
13. 4.15 Pediatric Weight for Hieght Observation Tests i. 4.15.01 Server returns valid results for Observation search by patient + code ii. 4.15.02 Server returns valid results for Observation search by patient + category + date iii. 4.15.03 Server returns valid results for Observation search by patient + category
    iv. 4.15.04 Server returns correct Observation resource from Observation read interaction v. 4.15.05 Server returns Provenance resources from Observation search by patient + code + revInclude:Provenance:target vi. 4.15.06 Observation resources returned during previous tests conform to the US Core Pediatric Weight for Hieght Observation Profile vii. 4.15.07 All must support elements are provided in the Observation resources returned viii. 4.15.08 MustSupport references within Observation resources can be read
14. 4.16 Laboratory Result Observation Tests i. 4.16.01 Server returns valid results for Observation search by patient + category
    ii. 4.16.02 Server returns valid results for Observation search by patient + category + date
    iii. 4.16.03 Server returns valid results for Observation search by patient + code iv. 4.16.04 Server returns correct Observation resource from Observation read interaction v. 4.16.05 Server returns Provenance resources from Observation search by patient + code + revInclude:Provenance:target vi. 4.16.06 Observation resources returned during previous tests conform to the US Core Laboratory Result Observation Profile vii. 4.16.07 All must support elements are provided in the Observation resources returned viii. 4.16.08 MustSupport refrences within Observation resources can be read
15. 4.17 Pediatric BMI for Age Observation Tests i. 4.17.01 Server returns valid results for Observation search by patient + code ii. 4.17.02 Server returns valid results for Observation search by patient + category + date iii. 4.17.03 Server returns valid results for Observation search by patient + category iv. 4.17.04 Server returns correct Observation resource from Observation read interaction v. 4.17.05 Server returns Provenance resources from Observation search by patient + code+ revIncludeProvenance:target vi. 4.17.06 Observation resources returned during previous tests confirm to the US Core Pediatric BMI for Age Observation Profile vii. 4.17.07 All must support elements are provided in the Observation resources returned viii. 4.17.08 MustSupport references within Observation resources can be read
16. 4.18.05 Server returns Provenance resources from Observation search by patient + code+ revInclude: Provenance: target i. 4.18.07 All must support elements are provided in the Observation resources returned
17. 4.19 Pediatric Head Occipital-frontal Circumference Percentile Tests i. 4.19.01 Server returns valid results for Observation search by patient + code ii. 4.19.02 Server returns valid results for Observation search by patient + category + date iii. 4.19.03 Server returns valid results for Observation search by patient+ category iv. 4.19.04 Server returns correct Observation resource from Observation read interaction v. 4.19.05 Server returns Provenance resources from Observation search by patient + revInclude: Provenance: target vi. 4.19.06 Observation resources returned during previous tests conform to the US Core Pediatric Head Occipital-frontal Circumference Percentile Profile vii. 4.19.07 All must support elements are provided in the Observation resources returned viii. 4.19.08 MustSupport reference within Observation resources can be read
18. 4.20 Observation Body Height Tests i. 4.20.05 Server returns Provenance resources from Observation search by patient + code+ revInclude: Provenance: target
19. 4.21 Observation Body Temperature Tests i. 4.21.05 Server returns Provenance resources from Observation search by patient + code + revInclude: Provenance: target
20. 4.22 Observation Blood Pressure Tests i. 4.22.05 Server returns Provenance resources from Observation search bypatient + code + revInclude: Provenance target
21. 4.23 Observation Body Weight Tests i. 4.23.05 Server returns Provenance resources from Observation search by patient + code + revInclude: Provenance: target
22. 4.24 Observation Heat Rate Tests i. 4.24.05 Server returns Provenance resources from Observation search by patient + code + revInclude: Provenance: target
23. 4.25 Observation Respiratory Rate Tests i. 4.25.05 Server returns Provenance resources from Observation search by patient + code + revInclude: Provenance: target
24. 4.26 Procedure Tests i. 4.26.04 Server returns Provenance resources from Procedure search by patient + code + revInclude: Provenance: target
25. 4.27 Encounter Tests i. 4.27.03 All must support elements are provided in the Encounter resources returned ii. 4.27.04 MustSupport references within Encounter resources can be read
26. 4.28 Organization Tests i. 4.28.03 All must support elements are provided in the Encounter resources returned
27. 4.30 Provenance Tests i. 4.30.01 Server returns correct Provenance resource from Provenance read interaction ii. 4.30.02 Provenance resources returned during previous tests conform to the US Core Provenance Profile iii. 4.30.03 All must support elements are provided in the Provenance resources returned iv. 4.30.04 Must Support references within Provenance resources can be read

Thank you so much

[Jammjammjamm]

Yes, a skip is a fail: https://github.com/onc-healthit/onc-certification-g10-test-kit/wiki/FAQ#q-what-is-the-difference-between-skipped-test-and-omitted-test

[monicasmith2022]

Hi Stephen, I was afraid of that but thank you so much for the quick response.