-
Notifications
You must be signed in to change notification settings - Fork 40
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
base: main
Are you sure you want to change the base?
Add CP to Extension mappings #16767
Conversation
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.OpenSSF Scorecard
Scanned Manifest Files |
7ed41b1
to
5294fcc
Compare
Quality Gate passedIssues Measures |
Integration Test Results 60 files 60 suites 37m 24s ⏱️ Results for commit 5294fcc. |
@@ -3418,6 +3418,99 @@ | |||
valueType: String | |||
hl7Use: XTN.12 | |||
|
|||
- Resource: Any |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this 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 |
There was a problem hiding this comment.
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.
This PR adds HL7 -> FHIR -> HL7 mappings for the HL7 Datatype CP. These are currently only being mapped for OML_O21 messages.
Test Steps:
Changes
composite-price
in the extension registry as a CP to Extension item.datatypes/MOC/Extension.yml
todatatypes/MOC/MOCExtension.yml
to better fit our naming convention.Checklist
Testing
./prime test
or./gradlew testSmoke
against local Docker ReportStream container?npm run lint:write
?Process
Linked Issues