Add QPP profiles to flexporter mapping file

[elsaperelli]

Summary

This PR adds profiles defined by the generated CMS Quality Payment Program (QPP) IG to the existing qicore flexporter mapping file.

New behavior

• New QI Core profiles defined: AdverseEvent, Communication, MedicationAdministration, MedicationDispense and Task.

Code changes

• synthea/qpp_qicore.yaml - renamed file and added additional QI Core profile creation
• synthea/README.md - updates to explain the changes to the mapping file

Testing guidance

• On a local instance of synthea, uncomment line 301 of src/main/resources/synthea.properties in order to use the terminology server.
• In the synthea root directory, run ./run_synthea -fm <path to qpp_qicore.yaml>
• Inspect the resources of the generated patient in the /output directory

[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 4589520

[lmd59]

Cleanup looks good, and the new resources are all working! Yay! A couple of comments about potentially making the data more relevant if we can do it easily enough. And a quick question: For resources that were already exported by synthea or the previous 130 mapping file, were there any fields from QPP that weren't already exported on those resources? Wondering in order to contextualize the upcoming task.

[lmd59]

We run the risk of creating unrealistic data when we select a random code. For this code set especially, a lot of the codes indicate a death, which may be problematic when the patient doesn't have other data indicating death. We can probably leave it for now and see how it turns out in testing as it may not actually be a big deal. If we want to be extra proactive, we could identify some common bad outcomes that come from synthea modules and create the AdverseEvent resource based on that. (I would guess that Synthea already endeavors to create some adverse events even if they're not labeled as such, and Dylan might have more insight into this.)

[elsaperelli]

Sounds good! Or, I am happy to not use randomCode here if it would make more sense to just pick a code from that list...but then we wouldn't have as much variability so I am open to either.

[dehall]

Off the top of my head I can't think of any adverse events in the modules, other than possibly some of the surgeries have a risk of death. I can look for some though if that's of interest.

This also makes me think there should be some way of saying "random code from these specific few codes" rather than requiring the use of a terminology server and a published ValueSet. I can probably get that implemented pretty quickly

[elsaperelli]

Cleanup looks good, and the new resources are all working! Yay! A couple of comments about potentially making the data more relevant if we can do it easily enough. And a quick question: For resources that were already exported by synthea or the previous 130 mapping file, were there any fields from QPP that weren't already exported on those resources? Wondering in order to contextualize the upcoming task.

To answer your question, no, I did not find any fields missing from the resources that were already exported by synthea or the previous 130 mapping file.

Regarding the status codes for some of the profiles that we have arbitrarily set in the mapping file, is it ok for me to go ahead and use randomCode for them now that Dylan added that functionality to Synthea?

[lmd59]

Just a recommendation for the .medication fields and a note for future tasking!

[lmd59]

Looks good! Nice updates!