Add pd1-4 mapping to Patient.generalPractitioner

[jbiskie]

This PR adds mapping for PD1-4. The field is backwards compatible in NIST/HL7 2.5.1 and we are adding to support the ETOR NBS use case. In FHIR, the field maps to/from Patient.generalPractitioner.

Test Steps:

1. Run integration tests, specifically test OML_O21 all segments and test PD1 populated with PD1-14-1 populated.

Changes

• Updates HL7v2 to FHIR mapping. The PD1-4 field is mapped to a Patient.generalPractitioner Practitioner reference. Note that PD1-3 maps to Patient.generalPractitioner, but uses an organization reference. Both fields support repetitions.
• Updates FHIR to HL7v2 mapping to move the Practitioner into PD1-4
• Updates test input and output files

Checklist

Testing

• Tested locally?
• Ran ./prime test or ./gradlew testSmoke against local Docker ReportStream container?
• Added tests? *Updated existing OML and PD1 tests to include PD1-4.

Process

• Are there licensing issues with any new dependencies introduced? N/A
• Includes a summary of what a code reviewer should test/verify?
• Updated the release notes?
• Database changes are submitted as a separate PR? N/A
• DevOps team has been notified if PR requires ops support? N/A

Linked Issues

• Fixes TI issue 1620: Add PD1 Mappings for OML Messages trusted-intermediary#1620

Specific Security-related subjects a reviewer should pay specific attention to

• Does this PR introduce new endpoints?
  • new endpoint A
  • new endpoint B
• Does this PR include changes in authentication and/or authorization of existing endpoints?
• Does this change introduce new dependencies that need vetting?
• Does this change require changes to our infrastructure?
• Does logging contain sensitive data?
• Does this PR include or remove any sensitive information itself?

If you answered 'yes' to any of the questions above, conduct a detailed Review that addresses at least:

• What are the potential security threats and mitigations? Please list the STRIDE threats and how they are mitigated
  • Spoofing (faking authenticity)
    • Threat T, which could be achieved by A, is mitigated by M
  • Tampering (influence or sabotage the integrity of information, data, or system)
  • Repudiation (the ability to dispute the origin or originator of an action)
  • Information disclosure (data made available to entities who should not have it)
  • Denial of service (make a resource unavailable)
  • Elevation of Privilege (reduce restrictions that apply or gain privileges one should not have)
• Have you ensured logging does not contain sensitive data?
• Have you received any additional approvals needed for this change?

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

OpenSSF Scorecard

Package	Version	Score	Details

Scanned Manifest Files

[github-actions]

Test Results

1 265 tests  ±0   1 261 ✅ ±0   7m 30s ⏱️ -8s
  164 suites ±0       4 💤 ±0 
  164 files   ±0       0 ❌ ±0 

Results for commit 0b029d7. ± Comparison against base commit c942a9a.

♻️ This comment has been updated with latest results.

[github-actions]

Integration Test Results

 60 files   60 suites   43m 34s ⏱️
428 tests 418 ✅ 10 💤 0 ❌
431 runs  421 ✅ 10 💤 0 ❌

Results for commit 0b029d7.

♻️ This comment has been updated with latest results.

[JFisk42]

Changes look good! 👍

[JFisk42]

Just a whole heap of context for what this comment is referring to (you can ignore this if you're already aware). The HAPI library will set the object type of some fields to NULLDT (as opposed to String or CE or XCN, etc.) which effectively means values cannot be mapped to those fields. To get around this we have been importing and modifying some of the java classes from HAPI so that we can set field to the most universal types.

[mkalish]

Looks great to me! Only thought would be to maybe update one of the integration tests for the ETOR use case to make sure that ORM -> FHIR is working for their sample

[GilmoreA6]

Looks great to me! Only thought would be to maybe update one of the integration tests for the ETOR use case to make sure that ORM -> FHIR is working for their sample

Hey Michael! Just want to clarify this is for the ETOR use case. Our partners are able to send us OML_O21 messages as it turns out so that's what we're mapping here. There's a couple more backwards compatible fields we'll be mapping but they are all for message type OML_021

[mkalish]

@GilmoreA6 Got it that makes sense!

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[jack-h-wang]

Progresses #15503.