BFD-3398: Prototypes Generation of FHIR Resource Transformers Flow with Identifier Element for DME EOB as Example

[meliGuzman]

JIRA Ticket:
BFD-3398

User Story or Bug Summary:

Prototype the DME EOB FHIR Resource Transformer for the identifier element.

---

What Does This PR Do?

This prototype is built on a previous prototype for the generation of an updated data dictionary. What's new here is the logic that generates source code for the FHIR Resource Transformers. I wanted to figure out the logical flow so I limited this prototype to just generating the DMEExplanationOfBenefitTransformer with just the identifier element being set. I modeled the logic similar lyto how BFD creates the regular transformers.

Notes:

• This prototype does not include any tests so to see the generated DMEExplanationOfBenefitTransformer you'll have to run: mvn clean install -DskipITs -DskipTests=true -Dmaven.build.cache.enabled=false -Dapidocgen.skip=false Once done, you'll then look under the target folder for bfd-model-rif, specifically under generated-sources.
• You'll notice that this prototype still contains the 1200+ json files. They are being used to bootstrap the creation of the FHIR resource yaml files, like Coverage.yaml, for now. Later, they would be officially removed and we'd switch to only reading from the FHIR Resource yaml files to create the updated data dictionary. I've kept them for now since more effort is needed to clean up some of the data so right now it defaults to using some of the data from the json files if it's unable to obtain updated data from what currently exists on BFD.
• You'll need to manually create the folder dist-temp at the root level since that's where I place the updated data dictionary

What Should Reviewers Watch For?

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

• Review & provide any feedback on the FHIR Resource yaml files so after running X, run cd apps/bfd-model/bfd-model-rif/target/generated-resource/fhirResources to take a look at ExplanationOfBenefit.yaml for example
• Review & provide any feedback on the generated DMEExplanationOfBenefitTransformer
• Let me know if you have any ideas to improve this!

What Security Implications Does This PR Have?

Submitters should complete the following questionnaire:

• If the answer to any of the questions below is Yes, then you must supply a link to the associated Security Impact Assessment (SIA), security checklist, or other similar document in Confluence here: N/A

  • Does this PR add any new software dependencies?
    • Yes
    • No
  • Does this PR modify or invalidate any of our security controls?
    • Yes
    • No
  • Does this PR store or transmit data that was not stored or transmitted before?
    • Yes
    • No

• If the answer to any of the questions below is Yes, then please add @StewGoin as a reviewer, and note that this PR should not be merged unless/until he also approves it.

  • Do you think this PR requires additional review of its security implications for other reasons?
    • Yes
    • No

What Needs to Be Merged and Deployed Before this PR?

This PR cannot be either merged or deployed until the following prerequisite changes have been fully deployed:

• Since this is just a POC, this won't be merged!

Submitter Checklist

I have gone through and verified that...:

• I have named this PR and branch so they are automatically linked to the (most) relevant Jira issue. Ie: BFD-123: Adds foo
• This PR is reasonably limited in scope, to help ensure that:
  1. It doesn't unnecessarily tie a bunch of disparate features, fixes, refactorings, etc. together.
  2. There isn't too much of a burden on reviewers.
  3. Any problems it causes have a small "blast radius".
  4. It'll be easier to rollback if that becomes necessary.
• This PR includes any required documentation changes, including README updates and changelog / release notes entries.
• The data dictionary has been updated with any field mapping changes, if any were made.
• All new and modified code is appropriately commented, such that the what and why of its design would be reasonably clear to engineers, preferably ones unfamiliar with the project.
• All tech debt and/or shortcomings introduced by this PR are detailed in TODO and/or FIXME comments, which include a JIRA ticket ID for any items that require urgent attention.
• Reviews are requested from both:
  • At least two other engineers on this project, at least one of whom is a senior engineer or owns the relevant component(s) here.
  • Any relevant engineers on other projects (e.g. DC GEO, BB2, etc.).
• Any deviations from the other policies in the DASG Engineering Standards are specifically called out in this PR, above.
  • Please review the standards every few months to ensure you're familiar with them.