Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add CP to Extension mappings #16767

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Conversation

JFisk42
Copy link
Collaborator

@JFisk42 JFisk42 commented Dec 10, 2024

This PR adds HL7 -> FHIR -> HL7 mappings for the HL7 Datatype CP. These are currently only being mapped for OML_O21 messages.

Test Steps:

  1. Integration tests pass

Changes

  • Added composite-price in the extension registry as a CP to Extension item.
  • Renamed the MOCExtension file from datatypes/MOC/Extension.yml to datatypes/MOC/MOCExtension.yml to better fit our naming convention.
  • Updated OML_O21 FHIR -> HL7 mappings to use the RS specific java classes

Checklist

Testing

  • Tested locally?
  • Ran ./prime test or ./gradlew testSmoke against local Docker ReportStream container?
  • (For Changes to /frontend-react/...) Ran npm run lint:write?
  • Added tests?

Process

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

Linked Issues

@JFisk42 JFisk42 added the platform Platform Team label Dec 10, 2024
Copy link

github-actions bot commented Dec 10, 2024

Dependency Review

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

OpenSSF Scorecard

PackageVersionScoreDetails

Scanned Manifest Files

@JFisk42 JFisk42 force-pushed the platform/josh/15490-cpextension branch from 7ed41b1 to 5294fcc Compare December 10, 2024 02:43
Copy link

Test Results

1 255 tests  ±0   1 251 ✅ ±0   7m 30s ⏱️ -18s
  164 suites ±0       4 💤 ±0 
  164 files   ±0       0 ❌ ±0 

Results for commit 5294fcc. ± Comparison against base commit 164926e.

Copy link

sonarcloud bot commented Dec 10, 2024

Copy link

Integration Test Results

 60 files   60 suites   37m 24s ⏱️
424 tests 414 ✅ 10 💤 0 ❌
427 runs  417 ✅ 10 💤 0 ❌

Results for commit 5294fcc.

@JFisk42 JFisk42 marked this pull request as ready for review December 10, 2024 22:50
@JFisk42 JFisk42 requested a review from a team as a code owner December 10, 2024 22:50
@@ -3418,6 +3418,99 @@
valueType: String
hl7Use: XTN.12

- Resource: Any
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As noted in standup, this pattern is somewhat cobbled together from other extension mapping patterns because of its uniqueness.

CP is somewhat unique in that:

  • It does not exist in the mapping inventory
  • It is a datatype that exists on multiple HL7 segments

With that in mind, the idea here is to create something that is more formalized than simply adding each field to Resource.extension by itself. This allows CP to be noted as such when it shows up, and makes it easier to send CP data if a FHIR sender ever needed to do so.

Still, this is what made sense to me, so if there is a format that better fits existing/future patterns I'm open to it.

@@ -1,6 +1,6 @@
# $schema: ./../../../../../../metadata/json_schema/fhir/fhir-to-hl7-mapping.json

hl7Class: ca.uhn.hl7v2.model.v27.message.OML_O21
hl7Class: fhirengine.translation.hl7.structures.fhirinventory.message.OML_O21
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was changed to get around some very uncommon edge cases. There is a ticket to update ORU-based mappings with the same change: #16755

This scenario appears to only occur for fields which have been Withdrawn between HL7 2.5.1 and 2.7. This causes the field type to be set to NULLDT by Hapi. This hasn't been an issue with other fields as Hapi will still handle them appropriate when going from a complex fhir type to NULLDT. However, in the case where the withdrawn field has complex subfields (Ex: IN1.38), there will be data modification or loss.

Copy link
Collaborator

@jack-h-wang jack-h-wang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All looks good to me!

specs: IN1.14
- expressionType: resource
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these values will move to IN1Extension but that doesn't have to be done now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
platform Platform Team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Create mapping for HL7 CP -> FHIR extension -> HL7 CP
2 participants