Date query builder uses name instead of xpath

[elsaperelli]

Summary

This PR fixes some _typeFilter functionality that we had slightly incorrect for mostly date search parameters. Now we can use the correct search parameters such as Encounter.onset-date.

New behavior

We now properly map search parameters to their xpath so that fhir-qb can properly build a search query. Before, the user could only use _typeFilter queries with the xpath, such as Encounter.onsetDateTime, when the correct search is Encounter.onset-date. This was simply a matter of making sure the parameterDefinitions had the correct keys when being passed into buildSearchQuery.

Code changes

• src/util/exportToNDJson.js - make sure the search param keys are the name
• test/util/exportToNDJson.js - change unit tests to have proper _typeFilter search parameters

Testing guidance

• npm run check
• npm run start
• Either use Insomnia to test _typeFilter ... OR (even better!) use the bulk-export-app to make testing even easier (yay Cooper!)
• Keep in mind that search parameters of type date that map to attributes of type period (ex. Encounter.date) will still not work as expected. This still needs to be addressed in our fork of node-fhir-server-core and there is a task for that in the BL!

[github-actions]

Coverage report

St.❔	Category	Percentage	Covered / Total
🟡	Statements	75.63%	574/759
🟡	Branches	63.19%	206/326
🟡	Functions	75.83%	91/120
🟡	Lines	75.87%	566/746

Test suite run success

95 tests passing in 8 suites.

Report generated by 🧪jest coverage report action from 30afd38

[lmd59]

One small code change recommendation inline!

Beyond that, I had difficulty testing this with something other than date-y like things as I couldn't find a field that is

used by our measure data
has a different search parameter name versus the field name
doesn't use a a date type
doesn't use some complex type who's value is an object (our matching on object things, like CodeableConcept seems to be broken as well unless I'm constructing the query incorrectly)
I instead found another example of a simple date query where the date is just a datetime (cannot be some other date-like thing), and I found that to be successful:
http://localhost:3000/$export?_type=DeviceRequest&_typeFilter=DeviceRequest%3Fauthored-on%3Deq2019-01-01T00%3A00%3A00.000Z

I think that we should probably add more testing of object-like (token/reference/etc.) search parameters to our backlog task, but after the comment change, this PR in and of itself can probably be pulled in.