Add USCore 3.1.1 test group, CRD profile tests

[elsaperelli]

Summary

This task adds US Core 3.1.1 tests to the Light DTR EHR Test Suite as well as tests for the Light DTR EHR REST Capabilities by Resource/Profile.

Originally, the goal of this task was to generate tests using the US Core generator with a capability statement that combined the US Core 3.1.1 capability statement and the Light DTR EHR Capability statement; however, the majority of the CRD Profiles are read only and the US Core generator read test generator relies on search tests in order to work. Therefore, the majority of the tests are handwritten, with the exception of the CRD Coverage patient and context search tests which were generated and brought over (along with the US Core generator infrastructure).

An additional thing to note is the use of the CDex Task profile in the Task validation test since there is seemingly no CRD Task profile.

Testing Guidance

• In order to test the CRD profile tests, I added a patient with CRD profile resources to a local instance of the inferno-reference-server. I have attached this patient JSON file below.
• In order to load the patient JSON into the local copy of the reference server, follow these steps:
  • Put the JSON file in the /resources directory
  • docker compose down
  • docker volume rm inferno-reference-server_fhir-pgdata
  • docker compose up --build
• In the Light DTR EHR test kit, use http://localhost:8080/reference-server/r4
• For the profile ids use the following for pat001:
  • coverage-example1
  • communicationrequest-example1
  • devicerequest-example1
  • encounter-example1
  • medicationrequest-example1
  • nutritionorder-example1
  • servicerequest-example1
  • cdex-task-example19
  • visionprescription-example, visionprescription-example2

Questions

• I am a bit confused about the IG's description of the Coverage search by context capability. I am not sure how to properly test that since it looks like the example CRD Coverage does not have a context field, nor does there seem to be one in the profile Snapshot table.
• Looks like the Ruby lint errors are coming from the US Core generator files that I had to bring over, what is the best way for me to address these?

dtr_bundle_patient_pat001.json

[karlnaden]

I am a bit confused about the IG's description of the Coverage search by context capability. I am not sure how to properly test that since it looks like the example CRD Coverage does not have a context field, nor does there seem to be one in the profile Snapshot table.

Well, this is interesting. I agree there is no context search parameter on the Coverage resource, not in base FHIR R4 or defined in DTR or CRD. Looking at the current build version of DTR, it looks like the Coverage resource was a mistake and that QuestionnaireResponse was intended. Some of the text in the published version suggests that as well, e.g. "This requires the server to provide access to the specified resources to allow such an app to retrieve and edit QuestionnaireResponses and related resources." and "context (reference): Allows retrieving QuestionnaireResponse for a context" and the context search parameter is defined in the published IG on QuestionnaireResponse.

I think this is probably enough for us to switch from Coverage to QuestionnaireResponse and so I think that is what we should do, but will get some leadership opinions before confirming.

[karlnaden]

There are a few other checks that the us core version of the read test performs around making sure that the read id and resource type is what gets returned - see rows 37 and 38. I think those should be added here.

[karlnaden]

a good example of simplified version of us core read test that steve wrote is this crd test.

[karlnaden]

let's also try to create a unit test for this one following the idea in this thread. Here's how you stub out responses from the system under test.

[karlnaden]

a few details to clean-up, but looking good

[karlnaden]

to address the ci Ruby / test failure, upgrade to us core test kit version 0.9.0 per steve.

[karlnaden]

looks like this method adds errors to the message set, but doesn't cause the inferno test to fail, so we need to do that step after it. Will be similar to this code, but should be a failure, not a skip.

[karlnaden]

I'd like to create a separate method for this and then create a unit test for it. The idea is that you can create an anonymous class with a run method and any associated details, and then run it. See this Subscriptions PR for some other infrastructure I'm trying to setup around unit testing and get feedback on that may be helpful. Note that you'll need to stub out calls to the validator as done here.

[karlnaden]

lets add some unit tests which should help fix the one issue I see