PULL REQUEST

Summary

This PR addresses a couple of bugs I found in the code while trying to chase down classType code handling that came up during Connectathon refactoring.

First, I removed the classTypecodes from queries, as we were never including any codes because no codes are included in the VSAC. The intent behind classTypecodes was to allow users to look up encounters by class type, e.g., for a Chlamydia query, give me all of the encounters that are classified as "Emergency room" visits. I think in practice this is not an ideal way to scope queries because the emergency room visits could be completely unrelated to the chlamydia case; you could end up repeating the sins of eCR by overloading users with too much extraneous information. However, I do believe users have expressed interest in seeing the encounter class type for the results that we do return by snomed/loinc codes, which brings us to the second update.

Second, I added formatCoding so that we would be able to correctly display classTypes if they are present in a bundle. We had previously been trying to process them as CodeableConcepts but they are Codings!

Third, I fixed a bug in checkIfSomeElementWithPropertyExists that would always return false even if an element was present in a resource. I also updated this function to check for multiple properties at once so that for Encounters we could check for class, serviceProvider, and serviceType in one go instead of looping over the encounters (and other resource types) multiple times.

What we used to display (no clinic type even though it existed in the data and we checked for it 🙈):

What we display now (clinic type is now visible!):

Related Issue

Fixes #300

Additional Information

We also now display the Reason Code in Medication Requests if they exist.

Old:

Anything else the review team should know?

Checklist

• Descriptive Pull Request title
• Link to relevant issues
• Provide necessary context for design reviewers
• Update documentation