Update DataProvider and PatientObject to allow async and be stricter

[mgramigna]

• Make currentPatient/nextPatient return PatientObjects and allow Promises
• Make findRecords allow promises

Pull requests into cql-execution require the following.
Submitter and reviewer should ✔ when done.
For items that are not-applicable, mark "N/A" and ✔.

CDS Connect and Bonnie are the main users of this repository.
It is strongly recommended to include a person from each of those projects as a reviewer.

Submitter:

• This pull request describes why these changes were made
• Code diff has been done and been reviewed (it does not contain: additional white space, not applicable code changes, debug statements, etc.)
• Tests are included and test edge cases
• Tests have been run locally and pass
• Code coverage has not gone down and all code touched or added is covered.
• Code passes lint and prettier (hint: use npm run test:plus to run tests, lint, and prettier)
• All dependent libraries are appropriately updated or have a corresponding PR related to this change
• cql4browsers.js built with npm run build:browserify if source changed.

Reviewer:

Name:

• Code is maintainable and reusable, reuses existing code and infrastructure where appropriate, and accomplishes the task’s purpose
• The tests appropriately test the new code, including edge cases
• You have tried to break the code

[codecov-commenter]

Codecov Report

Merging #298 (61f7c7e) into next (487797e) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             next     #298   +/-   ##
=======================================
  Coverage   86.13%   86.13%           
=======================================
  Files          50       50           
  Lines        4427     4427           
  Branches     1245     1245           
=======================================
  Hits         3813     3813           
  Misses        321      321           
  Partials      293      293           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[benMain]

@mgramigna Dude, why are you trying to make this slower by having patient resolved async (presumably via some http request). Its slow enough already.

[mgramigna]

@mgramigna Dude, why are you trying to make this slower by having patient resolved async (presumably via some http request). Its slow enough already.

The idea is to allow data providers to the engine to be asynchronous if they want to be. They don't have to be. Some ideas that were shared with us for this were not only HTTP requests but also database calls or something like that so you don't need to load all the patient data in memory in order to do execution, which might not scale well for some cases. We're looking for feedback and testing on the async stuff, that's why it's in beta.

No one is forced to implement async patient providers, and the worst thing that will happen is the engine might await something that isn't actually a Promise, which should be a negligible performance hit if any at all. I'm happy to test this statement more though and may even be proven wrong.

With the test cases that my team ran using an async CQL engine, we did not notice any slowdowns.

[ssayer]

@mgramigna Dude, why are you trying to make this slower by having patient resolved async (presumably via some http request). Its slow enough already.

Hi @benMain, Thank you for bringing to our attention that we forgot to add an actual link to our code of conduct mentioned in our change management guide. That is an oversight, and I've already talked to @cmoesel about fixing that.

I'm not sure why you decided to edit your post to add an extra insult, but this type of language is not acceptable and deters people from contributing to open source. As @mgramigna noted there are many different use cases for this engine, and we are trying to support them. If a certain feature doesn't work for you, you have several options:

1. Don't use it
2. Submit a PR
3. Fork the project
4. Use a different CQL engine

[cmoesel]

Thanks, @mgramigna! This looks great. I'm sure that implementers will appreciate the clarity regarding what the engine expects/allows.