BCDA-9876: enable pac data v3 ssp

[bhagatparwinder]

🎫 Ticket

https://jira.cms.gov/browse/BCDA-9876

🛠 Changes

New Behavior:

• SSP model entities can access both partially adjudicated and adjudicated claims data via BCDA v3
• KCC model entities can access only adjudicated claims data

ℹ️ Context

We don't plan to add any new model types for v1/v2 access. Like IOTA, any new models should be limited to v3. Going forward, the default will be access to both adjudicated and partially adjudicated claims data via v3.

🧪 Validation

Unit test suite

[carlpartridge]

Looking at the long list of acceptance criteria in the ticket it feels like we should have more tests. Or are most of these existing logic and covered by existing tests?

[bhagatparwinder]

Looking at the long list of acceptance criteria in the ticket it feels like we should have more tests. Or are most of these existing logic and covered by existing tests?

All of it is existing on how our endpoints behave. The difference we are making now is everyone has access to PAC and non PAC data on V3 except KCC.

[michaeljvaldes]

As a side note, the configs in the config s3 buckets will probably need to be updated as well when this PR is merged.

[bhagatparwinder]

As a side note, the configs in the config s3 buckets will probably need to be updated as well when this PR is merged.

We control those through SOPS now, correct? I can make the SOPS edit in this PR.

[michaeljvaldes]

As a side note, the configs in the config s3 buckets will probably need to be updated as well when this PR is merged.

We control those through SOPS now, correct? I can make the SOPS edit in this PR.

Unfortunately, due to obstacles in injecting environment variables in the ECS task definitions, the param store values that are files are not grabbed from SOPs/param store -- instead, they're grabbed from the environment's config bucket.
I think there are improvements we can make, possibly to link the SOPs values to the bucket files, but maybe that will be influenced a bit by where our automatic credential rotation takes us in terms of relevant tools.

[bhagatparwinder]

As a side note, the configs in the config S3 buckets will probably need to be updated as well when this PR is merged.

We control those through SOPS now, correct? I can make the SOPS edit in this PR.

Unfortunately, due to obstacles in injecting environment variables in the ECS task definitions, the param store values that are files are not grabbed from SOPs/param store -- instead, they're grabbed from the environment's config bucket. I think there are improvements we can make, possibly to link the SOPs values to the bucket files, but maybe that will be influenced a bit by where our automatic credential rotation takes us in terms of relevant tools.

Got it. I will update the S3 config files post PR merger, before release.

[carlpartridge]

As a side note, the configs in the config S3 buckets will probably need to be updated as well when this PR is merged.

We control those through SOPS now, correct? I can make the SOPS edit in this PR.

Unfortunately, due to obstacles in injecting environment variables in the ECS task definitions, the param store values that are files are not grabbed from SOPs/param store -- instead, they're grabbed from the environment's config bucket. I think there are improvements we can make, possibly to link the SOPs values to the bucket files, but maybe that will be influenced a bit by where our automatic credential rotation takes us in terms of relevant tools.

Got it. I will update the S3 config files post PR merger, before release.

Quick reminder that you will need to update both the api and worker config files in their own respective buckets.