BFD-4499: Expand use of Claim Audit Trail Status Code

[mel1-G]

JIRA Ticket:
BFD-4499

What Does This PR Do?

• Expanded use of CLM_AUDT_TRL_STUS_CD for more claim type codes, which included updating the IdrClaim model to join with location history & selecting the record with the highest CLM_LCTN_CD_SQNC_NUM
• Separated out two concept maps for FISS & MCS for CLM_AUDT_TRL_STUS_CD since some codes overlap but have different outcomes
• Updated FML .map to use CLM_AUDT_TRL_STUS_CD to set the outcome and create a supporting info component for shared systems claims
• Since there exists some overlap between FISS & MCS and VMS is dependent on both status code (CLM_AUDT_TRL_STUS_CD) and location code (CLM_AUDT_TRL_LCTN_CD), we're deriving the claim status code using source (META_SRC_SK), status code, and location code. This is the logic:

FISS & MCS --> concatenation on the source & status code (eg FD/MD)
VMS --> concatenation of source, location code, & status code (eg V0800)
This composite code is what gets set in the supporting info component

• Added augmented CLM_AUDT_TRL_STUS_CD codesystem
• Implemented META_SRC_SK on the server (https://jira.cms.gov/browse/BFD-4481)
• Fixed some old validation errors by adding some missing fields to CodeSystem-Supporting-Information.fsh
• Updated augment_sample_resources.py to generate the composite status code
• Updated bfd-model-idr readme to explain how to test FML map changes

What Should Reviewers Watch For?

If you're reviewing this PR, please check for these things in particular:

• Checkout the updated claim query in model.py

What Security Implications Does This PR Have?

Please indicate if this PR does any of the following:

• Adds any new software dependencies

• Modifies any security controls

• Adds new transmission or storage of data

• Any other changes that could possibly affect security?

• I have considered the above security implications as it relates to this PR. (If one or more of the above apply, it cannot be merged without the ISSO or team security engineer's (@sb-benohe) approval.)

• I have created tests to sufficiently ensure the reliability of my code, if applicable. If this is a modification to an existing piece of code, I have audited the associated tests to ensure everything works as expected.

Validation

Have you fully verified and tested these changes? Is the acceptance criteria met? Please provide reproducible testing instructions, code snippets, or screenshots as applicable.

• Verified compiled resources have the EOB outcome and supporting info component that I expect
• updated integ test data and verified that the snapshots have the EOB outcome and supporting info component that I expect

[aschey-forpeople]

Would it be worth moving src, status, and claimAuditTrailLocationCode into their own embedded class? Seems like they're closely related here.

[mel1-G]

i like that. Moved!

[bfd-sast]

Quality Gate passed for 'bfd-parent'

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
95.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[aschey-forpeople]

I think maybe we can combine the tryFromCode and toFhir method here? Feels like that fits with our existing patterns better. The enum converter pattern with tryFromCode is mostly designed to work with a single field at the DB -> Java conversion layer.